0

whenever I write data to a tcp socket, it waits until its filled with enough data ex: 64k (max packet size) then it sends data to the wire. this misses the data at the right time for the other end.

when I set TCP_NODELAY, any data written to socket is sent to the wire immediately. this reduces the bandwidth as we have lots of small packets with ACKs.

can we set a rule for linux to flush out sockets conditionally? ex:

if time gap between last sent packet and current data is greater than 100ms send immediately no matter how much data lendth is
else if current data length is bigger than 50kb send immediately no matter how much time gap is
else do nothing, wait some milliseconds for next decision

I dont want to reduce tcp buffer size, want to modify how linux flushes data out.

can we do this just by playing with linux configuration files? or this must be implemented in each software written?

any direct answer, help, solution or link to an article, is appreciated

8
  • 1
    100 kB?! more like 1000B. Network packets aren't that large. Commented Aug 15, 2023 at 11:28
  • I mean up to max packet size Commented Aug 15, 2023 at 11:30
  • I don't think the socket layer does any delayed buffering; any buffering would be receiving packets. If you write one byte, it should immediately send one byte. Are you sure it isn't a library above the socket layer doing it?
    – user10489
    Commented Aug 15, 2023 at 11:30
  • @user3840019 then please fix your question to say that, and not something else. Commented Aug 15, 2023 at 11:30
  • 1
    @user10489 it does, Nagle's algorithm Commented Aug 15, 2023 at 11:31

1 Answer 1

1

else if current data length is bigger than 50kb send immediately no matter how much time gap is

That happens anyways. Transmit buffering windows for Nagle's algorithm aren't larger than underlying-layer packets (i.e., the MTU), as that would have no benefit, and these will in all practical applications not be larger than 9 kB. So, I kind of get the feeling you have a different problem than what you think you have.

if time gap between last sent packet and current data is greater than 100ms send immediately no matter how much data lendth is

That happens – anyway, unless you explicitly used TCP_CORK, and even then, the latency would be limited to 200 ms.

Again, I get the feeling you have a very different problem than you think you have.

else do nothing, wait some milliseconds for next decision

Note that the proper "decision" to your problem requires application-level knowledge of your dataflow requirements – so, actually, the simplest, and an especially low-overhead solution, is to design your protocol accordingly, and accumulate small datagrams before transmitting them in your application, and then flush manually (or using TCP_NODELAY). You can also peruse setting and unsetting TCP_CORK to have the Linux kernel do the accumulation for you.

This might mean you need to drop TCP and go for SCTP, or in the extreme case, for UDP with your own flow control logic – which you really seem to want, considering your initial statement:

this misses the data at the right time for the other end.

This sounds like you misdesigned a network protocol using assumptions that are wrong for TCP? The TCP does not guarantee packet ordering between RX and TX; only per RX and TX individually, the data order is guaranteed.

9
  • I mean by missing, the other end not recieving at exact time, because data is unusable after that delay. because its a tunnel for carrying udp packet over tcp Commented Aug 15, 2023 at 11:51
  • yeah, carrying UDP packets over TCP is questionable to begin with, and obviously can end in deadlock situations if whatever does the flow control over UDP has different assumptions. So, UDP over TCP can really only work in general with TCP_NODELAY. Otherwise, the UDP flow controller must have assumptions that are compatible with the TCP flow control. Commented Aug 15, 2023 at 11:54
  • the carrier is a highly stable network and no packets are dropped, the only thing is there just some one-byte data which I want to mix them in each 50ms then send them as single packet. to reduce ping-pong mechanism of tcp Commented Aug 15, 2023 at 11:57
  • this even more clearly says that putting your UDP into TCP is a bad idea and shouldn't be done! Commented Aug 15, 2023 at 11:58
  • yes I know that, but the firewall in network blocked udp Commented Aug 15, 2023 at 12:00

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .