UDP

[winksaville]

When creating an SM you generally assume that messages sent from a particular peer arrive ordered and without loss. To assume otherwise makes creating the SM astronomically harder.

Thus, I suggest not using UDP directly and instead build a new messaging specific protocol on top of UDP (to much work) or choose an existing reliable protocol.

Thoughts?

[stuartmscott]

I guess the main requirements are;

1. Ordered Messages - a way for a message to indicate its sequence in the conversation.
2. Acknowledged Message - sender knows the receiver received the message.
3. Automatic Retry - sender resends unacknowledged message after some timeout, and an error is generated if multiple retries fail.
4. Valid Messages - a way for a receiver to check the message arrived intact.

Anything missed?

[winksaville]

My feature list is in 39

[stuartmscott]

I agree with most of them; non-blocking (although it will block until ack is received, or a timeout occurs so really there is an upper bound on blocking), constant time, lossless, ordered.

There are some I'm not so sure about;

Sending does not mean message will be received

Isn't that the goal here? - If a message is send it will either be received, or Send will return false.

Notify sender & receiver on disconnect

If a connection is not being actively used, do the pair care if the network drops in and out? I think they only really need to care if a send fails. The only way to actually do this is with heartbeat messages, and we already have heartbeats for the supervision tree so parents can monitor their children. Adding heartbeats to every conversation would dramatically increase network traffic.

[winksaville]

I agree with most of them; non-blocking (although it will block until ack is received, or a timeout occurs so really there is an upper bound on blocking), constant time, lossless, ordered.

For now no big deal but long term sending needs to be absolutely as fast as possible as it effects a MaCHines (MCH)s liveliness. When #39 is completed all sends should never block.

There are some I'm not so sure about;

Sending does not mean message will be received

Isn't that the goal here? - If a message is send it will either be received, or Send will return false.

If a MCH dies, messages in transit will never be received, so receiving cannot be guaranteed, this is why "pulsing" and "message timeouts" are required.

Notify sender & receiver on disconnect

If a connection is not being actively used, do the pair care if the network drops in and out? I think they only really need to care if a send fails. The only way to actually do this is with heartbeat messages, and we already have heartbeats for the supervision tree so parents can monitor their children. Adding heartbeats to every conversation would dramatically increase network traffic.

Agreed, individual connection heartbeats are not need for "local message passing" but might be needed "network" protocols.

[stuartmscott]

I think we might need an UnreliableSocket so we can test and benchmark how communications are impacted by delays and disconnections.

[winksaville]

Definitely, probably parametrized with some type of specifiable probability curves for error rate, RTT, throughput ... when complete.

[stuartmscott]

I'm sure there are many existing protocols, but let's see how hard it would be;

1. A message could have the first couple bytes be a sequence number.
2. The receiver replies ack <sequence> for any message received.
3. The sender awaits an ack and times out after a while, retries 3-5 times. Send could return a boolean success.
4. UDP spec already includes a CRC component, but I haven't implemented that yet.

[winksaville]

I'm sure there are many existing protocols, but let's see how hard it would be;

1. A message could have the first couple bytes be a sequence number.
2. The receiver replies ack <sequence> for any message received.
3. The sender awaits an ack and times out after a while, retries 3-5 times. Send could return a boolean success.
4. UDP spec already includes a CRC component, but I haven't implemented that yet.

That's a start, but whatever the actual list is, every SM and possibly ever state would have to handle it, IMHO, this should be "guaranteed" somewhere below the person coding the SM.

[stuartmscott]

Yes I'm exploring what feature would go into the framework itself.