dotsTheMessenger loses messages over a physical network.

[GoogleCodeExporter]

Since it uses UDP sockets, dotsTheMessenger is vulnerable to losing messages 
when using a physical network.  This was a problem when I was testing 
dotsTheComputablesManager between OS X and Windows machines.

dotsTheMessenger should wait for an ACK during sendMessageFromSocket().  It 
should make some effort to resend a message that goes unACKed.  
receiveMessageAtSocket() should send back an ACK when it gets a message, before 
returning.

sendMessageFromSocket()
  * should use a resendInterval and resendAttempts to resend unACKed messages a few times
  * should return the time it took to get an ACK, or else negative
  * should prepend each message with a one-byte serial number
  * should expect the current serial number as the ACK
  * should use a very small (zero?) polling interval when waiting for ACK
  * should receive at all open sockets when waiting for ACK, in the interest of same-Matlab client-server mode.

receiveMessageAtSocket()
  * should strip the one-byte serial number from each message
  * should send back the serial number as the ACK before it returns
  * should keep track of the previous serial number and ignore any new messages that arrive with the same number (in case of accidental resends)
  * should ignore stray ACK values it may receive from time to time

In context:
  * should be opaque to calling classes, like remote object managers
  * calling classes like remote object managers should keep track of ACK times as well as full transaction times (which include behaviors, not just communication)
  * should allow a per-transaction measure of client and server clock offsets
  * would allow client *and* server side to resend as needed

A potential problem:
  * when running in one Matlab instance, with both client and server mode true, would be tough to wait for ACK and send ACK at the same time.  Thus, sendMessageFromSocket() must poll at other open sockets while waiting for ACK.
  * if the polling also consumes the message, then it could go unseen by the caller.  Could it be buffered by dotsTheMessenger and returned on the next receiveMessageAtSocket()?  
  * or, if the polling does not consume the message, it might be hard to know whether it was a real message (as opposed to a stray ack).  It would also be hard to know at which other open socket a message needs to arrive.
  * it seems ridiculous for sendMessageFromSocket() to require a reference to the receiving socket.  Maybe it could take a waitFevalable which could be a no-op or a stand-in for the remote machine--the same behavior as waitForMessageAtSocket().
  * is there not a simpler way to deal with the single-Matlab case?  It would be better if sendMessageFromSocket() required no detailed hints.
  * maybe sendMessageFromSocket() should just take an argument, whether or not to wait for ACK and retry.  Callers like remote object managers could device based on client and server mode.

Original issue reported on code.google.com by Benjamin.Heasly on 2 Oct 2010 at 9:54

[GoogleCodeExporter]

sendMessageFromSocket() should not take a waitFevalable, like 
waitForMessageAtSocket(), because sendMessageFromSocket() should never be 
expected to consume messages or carry out behaviors.  It should always be able 
to return before a message is acted on by the recipient.

So waiting for ACK and resending should be optional.  When client and server 
mode are both true ACK behavior would be unnecessary because there would be no 
physical network.  So it's OK if that single-threaded behavior would also be 
difficult to implement.  The option can be a mustACK argument, and this is a 
reasonable, non-detailed hint for a messenger class to take.

This behavior is different from waitForMessageAtSocket(), which really does 
need a waitFevalable in order to carry out concurrent server-side behaviors 
during a blocking client-side function call.

Original comment by Benjamin.Heasly on 2 Oct 2010 at 10:41

[GoogleCodeExporter]

As of r421 this is implemented as written: ACK and retry behavior are part of 
dotsTheMessenger.

Also required a socket reset (without closing the socket) to refresh internal 
accounting of message serial numbers.

Original comment by Benjamin.Heasly on 8 Oct 2010 at 10:01

• Changed state: Fixed