侦听UDP套接字并转发到TCP套接字（可能是Java）

Question

有没有一种方法可以通过UDP侦听器侦听UDP数据包，然后将数据转换为字符串或其他任何内容，然后通过TCP套接字发送到TCP服务器，我对UDP不太熟悉，因此任何技巧都很棒

Answer 1

I wouldn't worry about UDP to TCP I would worry about the other way around.

You can't receive what you can't fit in your buffer through UDP so all receives will translate to one or more TCP sends.

TCP on the other hand is a segment based protocol and you may receive only the part of the reassembled segment which has been acknowledged and is available to the application buffer, this may not be the entire application layer message in all cases as I will illustrate.

Let Data = 30,000 bytes of data...

To get this data somewhere in the machine you can just pass a pointer but to get it to another machine you have to use a network or hardware application which is typically accessed via a driver.

Sockets are a common design paradigm or more succinctly interface which allows vastly different networks and mediums to communicate heterogeneously...

Through a socket you can simply worry about the protocol such as IP or TCP or UDP maybe ICMP and you don't have to worry about how the data gets to the hardware.

The network stack usually is a component of the operating system which inter-operates with the hardware and software drivers and is hidden behind the Socket interface such that the semantics of the hardware and network do not matter when only the protocol is of concern...

Back to Data...

The data sent will be split into several packets which can fit on the network medium, this is usually called the Maximum Transmittable Unit.

It allows the the required header fields of the medium as well as a sufficient amount of data to allow for flow control to a driver.

The driver receives this data and creates network packets which can be trivially sent and received on the medium and local machine network.

To get to the physical network additional layers must be added to the packet such as the IP and protocol headers, in this case TCP.

The network stack let's the driver know Data is ready to be sent during a call to send.

The data is copied to the network stack and the application can proceed (TCP or UDP)

Segments are created by the protocol in the maximum segment size or less under tcp and they are transmitted.

When any one segment is received and acknowledged is can be received by a call to recv .

The order of the data is maintained by the network stack and if an entire segment is not received it is re-transmitted.. if part of a segment is recieved it is held until the segments which preceeded it were recieved and acknowledged.

Some implementations of TCP allow for partially recieved segments to be made available to the application buffer (either with a special configuration or otherwise, usually with disabling tcp retransmission as well as send and receive coalescing but not limited to) even though loss or fragmentation has occurred within part of a segment during reception, usually the remainder of the segment is recieved and made available to the application during the next recieve however it's totally possible that more data arrives from a new segment and the old data either never does or arrives so late that your application is not eligible to recieve data which was already released to the application.

Thus you will normally and eventually receive 30,000 bytes at the receiving end (actually quite a bit more due to IP and TCP overhead) but it's quite possible in certain situations that you receive data out of order or not at all, this can be due to hardware failure on a route in between you and the receiver and is certainly not the norm but it can indeed happen.

In such cases the application layer should be able to determine when this anomaly occurs either by using a sequence number within the application protocol or by scanning the IP and TCP headers which can be achieved in various ways.

Hopefully that is enough to get you thinking... Please also see When sending data larger than the SendBufferSize, how will the data be received?