[Haskell-cafe] network package and SIGVTALRM

[Ruben Astudillo]

On 13/07/16 14:54, Andrey Sverdlichenko wrote:
> If you are lucky. They still may be merged by sender if retransmission
> occurs, or on receiving side, if receiver waits too long before reads, and
> this is up to OS scheduler to control.
> NDELAY option is used to improve interactive latency, it will not make TCP
> obey message boundaries.

You're right. But understanding a little better the problem maybe will
clarify why NODELAY is a valid option. DCC is in parts a redundant
protocol. When you connect, the senders gives you the file you want but
for coherency reasons every once in a while you have to reply the current
transfered size through the same socket. This was a mean of preserving
consistency that is redundant by the same mechanisms implemented on TCP.
 From the page[1] I am using to implement

   ``client A sends blocks of data (usually 1-2 KB) and at every block awaits
   confirmation from the client B, that when receiving a block should reply
   4 bytes containing an positive number specifying the total size of the
   file received up to that moment.

   The transmission closes when the last acknowledge is received by client A.

   The acknowledges were meant to include some sort of coherency check in
   the transmission, but in fact no client can recover from an acknowledge
   error/desync, all of them just close the connection declaring the
   transfer as failed (the situation is even worse in fact, often
   acknowledge errors aren't even detected!).

   Since the packet-acknowledge round trip eats a lot of time, many clients
   included the send-ahead feature; the client A does not wait for the
   acknowledge of the first packet before sending the second one.''

The last part explains why my download still succeded until half the size
of the file. But no sending any reply (because the message is too little
to send) is a failure of interactivity on the protocol, not of message
boundaries (which specify that the reply is 4 byte in length).

[1]: http://www.kvirc.net/doc/doc_dcc_connection.html
--
-- Ruben Astudillo