Sending data in separate TCP packets using Visual C++
-
Hello, I use Visual C++ and I work with network sockets (MFC's CAsyncSocket and winapi socket functions). My application need some data to be sent in separate TCP packets. In other words I must be sure that some data are sending immediately and want to avoid a situation when this data will wait for the next data to join with them in a single packet. How can I achieve this? I tried to use both CAsyncSock::SetSockOpt() method and direct winapi's setsockopt() call to set TCP_NODELAY option, but they DON'T WORK, so I see in network packets analyzer. Any suggestions will be very appreciated. Thanks in advance.
-
Hello, I use Visual C++ and I work with network sockets (MFC's CAsyncSocket and winapi socket functions). My application need some data to be sent in separate TCP packets. In other words I must be sure that some data are sending immediately and want to avoid a situation when this data will wait for the next data to join with them in a single packet. How can I achieve this? I tried to use both CAsyncSock::SetSockOpt() method and direct winapi's setsockopt() call to set TCP_NODELAY option, but they DON'T WORK, so I see in network packets analyzer. Any suggestions will be very appreciated. Thanks in advance.
As I'm not aware of the overall purpose of your application it's a little hard to be more specific, but here are a few thoughts. If you want to send single packets you'll have to use UDP not TCP. There is no way to *guarantee* that TCP/IP packets won't be aggregated, either on your machine, or at some other point along the wire. UDP of course doesn't offer guaranteed delivery so you'll have to engineer that functionality yourself. Here's a snippet from Warren Young's Winsock Programmers FAQ that you might find helpful: The whole document is found here >.3.17 - When should I turn off the Nagle algorithm? Generally, almost never. Inexperienced Winsockers usually try disabling the Nagle algorithm when they are trying to impose some kind of packet scheme on a TCP data stream. That is, they want to be able to send, say, two packets, one 40 bytes and the other 60, and have the receiver get a 40-byte packet followed by a separate 60-byte packet. (With the Nagle algorithm enabled, TCP will often coalesce these two packets into a single 100 byte packet.) Unfortunately, this is futile, for the following reasons: Even if the sender manages to send its packets individually, the receiving TCP/IP stack may still coalesce the received packets into a single packet. This can happen any time the sender can send data faster than the receiver can deal with it. Winsock Layered Service Providers (LSPs) may coalesce or fragment stream data, especially LSPs that modify the data as it passes. Turning off the Nagle algorithm in a client program will not affect the way that the server sends packets, and vice versa. Routers and other intermediaries on the network can fragment packets, and there is no guarantee of "proper" reassembly with stream protocols. If packet arrives that is larger than the available space in the stack's buffers, it may fragment a packet, queuing up as many bytes as it has buffer space for and discarding the rest. (The remote peer will resend the remaining data later.) Winsock is not required to give you all the data it has queued on a socket even if your recv() call gave Winsock enough buffer space. It may require several calls to get all the data queued on a socket. Aside from these problems, disabling the Nagle algorithm almost always causes a program's throughput to degrade. The only time you should disable the algorithm is when some other consideration, such as packet timing, is more important than th
-
As I'm not aware of the overall purpose of your application it's a little hard to be more specific, but here are a few thoughts. If you want to send single packets you'll have to use UDP not TCP. There is no way to *guarantee* that TCP/IP packets won't be aggregated, either on your machine, or at some other point along the wire. UDP of course doesn't offer guaranteed delivery so you'll have to engineer that functionality yourself. Here's a snippet from Warren Young's Winsock Programmers FAQ that you might find helpful: The whole document is found here >.3.17 - When should I turn off the Nagle algorithm? Generally, almost never. Inexperienced Winsockers usually try disabling the Nagle algorithm when they are trying to impose some kind of packet scheme on a TCP data stream. That is, they want to be able to send, say, two packets, one 40 bytes and the other 60, and have the receiver get a 40-byte packet followed by a separate 60-byte packet. (With the Nagle algorithm enabled, TCP will often coalesce these two packets into a single 100 byte packet.) Unfortunately, this is futile, for the following reasons: Even if the sender manages to send its packets individually, the receiving TCP/IP stack may still coalesce the received packets into a single packet. This can happen any time the sender can send data faster than the receiver can deal with it. Winsock Layered Service Providers (LSPs) may coalesce or fragment stream data, especially LSPs that modify the data as it passes. Turning off the Nagle algorithm in a client program will not affect the way that the server sends packets, and vice versa. Routers and other intermediaries on the network can fragment packets, and there is no guarantee of "proper" reassembly with stream protocols. If packet arrives that is larger than the available space in the stack's buffers, it may fragment a packet, queuing up as many bytes as it has buffer space for and discarding the rest. (The remote peer will resend the remaining data later.) Winsock is not required to give you all the data it has queued on a socket even if your recv() call gave Winsock enough buffer space. It may require several calls to get all the data queued on a socket. Aside from these problems, disabling the Nagle algorithm almost always causes a program's throughput to degrade. The only time you should disable the algorithm is when some other consideration, such as packet timing, is more important than th
Interestingly enough, I'm looking at the same problem. I'm working with real-time control systems. The real-time OS is sending data to a monitoring station, which must be updated as soon as possible, and packet sizes can often be as little as 20 bytes. Thankfully data doesn't always change constantly, so network bandwidth isn't the issue, but rather notifying the client as soon as possible is.