Re: Threads, conditions, sockets, selects...

"David Schwartz" <davids@xxxxxxxxxxxxx> writes:

malc wrote:

Full source is available at: http://www.boblycat.org/~malc/thtestc.c
Yes i do use TCP. It's dribbling (original version just sends 1 char),
but this is reasonable chunk from the applications perspective.

Right, but it's not reasonable from the TCP stack's perspective. The
problem is that the TCP stack has no way to tell when it should send a
packet, so it guesses.

I'd like to note that i'm by no means an expert in networking and can't
see the relation between TCP acks and the problem at hand.

You write one byte. The network stack has no way to know that that's
not the last byte you're going to write, so it sends it immediately.
You send another byte. Now the network stack has no way to know you're
not going to send another, so it delays the send until the previous
byte is acknowledged by the other end.

If the other end replies, the acknowledge will piggy-back on the reply.
When the sender gets the acknowledge, it will send the next chunk.

If the other end does not reply, it will not acknowledge the first byte
immediately. So the sender will not send the next chunk immediately.


Aha. Thank you for thorough explanation.

0.016 (250HZ Linux kernel) is on the order of 200 milliseconds.

Yep. You need to stop calling 'send' when there's going to be more data
almost immediately. Only call 'send' when you have at least 2KB of
data, you know there will not be any more data until the other side
sends some, or you know you will need a quite bit of computation before
more will be ready.

There will NEVER be data available almost immediately. Data arrives
every N milliseconds, furthermore the data size is huge so the server
merely notifies the clients that there is new data available, client
fetches it via other means.

One ugly fix is to write your own 'send' function that adds the data to
a buffer rather than sending it directly. Have your 'recv' function
flush the buffer, flush the buffer if it exceeds 2Kb, and flush it
every 20 milliseconds or so from a timer. (Or, better, call a flush
function after you're done generating data and going to block on
network data.)

Thanks for suggestion but this will not work in this particular case.
Here server only sends data description and client merely informs the
server when it's done using it.

Sockets were chosen for a few reasons: brevity, multiplexing and
portability. The real-data is not available across network anyway.
I guess some other form of IPC is more appropriate here, but this,
sadly, will take the "cheap" portability away.

Once again - thank you, this has been very educational.

--
mailto:malc@xxxxxxxxxxxxx
.

Relevant Pages

  • Re: Threads, conditions, sockets, selects...
    ... but this is reasonable chunk from the applications perspective. ... but it's not reasonable from the TCP stack's perspective. ... When the sender gets the acknowledge, it will send the next chunk. ... flush the buffer, flush the buffer if it exceeds 2Kb, and flush it ...
    (comp.unix.programmer)
  • Re: Removing T/TCP and replacing it with something simpler
    ... > I intend to remove T/TCP support from our TCP ... Good reasons & decision Andre. ... Another reason is that T/TCP is listed as "deprecated" in the ...
    (freebsd-arch)
  • Re: Removing T/TCP and replacing it with something simpler
    ... > I intend to remove T/TCP support from our TCP ... Good reasons & decision Andre. ... Another reason is that T/TCP is listed as "deprecated" in the ...
    (freebsd-net)
  • Re: C# Async Socket timeouts
    ... I have many reasons for not getting a response, and TCP issues are not ... I am talking to embedded systems over cellular and ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Threads, conditions, sockets, selects...
    ... but this is reasonable chunk from the applications perspective. ... but it's not reasonable from the TCP stack's perspective. ... The network stack has no way to know that that's ... When the sender gets the acknowledge, it will send the next chunk. ...
    (comp.unix.programmer)