Resume merge and fix

[lipp]

No description provided.

[lipp]

@markert @mloy @gatzka : review would be nice, since pretty hard to test. For resume "playground" see here

[mloy]

Your test does work fine. Unfortunately several other processes on the executing machine might rely on the loopback device.

How about starting a private jetd on another port instead. Then connect the peer to that jetd, kill that jetd and restart it.

[mloy]

I do have one question,

in order to be able to replay all changes until reconnecting to jetd/peer, the peer and jetd keep a ring buffer of the messages to be send. How do both know, that the message was send succesfully and can be removed from that ring buffer?

[lipp]

@mloy : "How about starting a private jetd on another port instead. Then connect the peer to that jetd, kill that jetd and restart it."
Killing jetd instead of shutting down the interface won't work, since the jetd also buffers messages etc. You cannot resume a connection after jetd closed.

[lipp]

@mloy : "How do both know, that the message was send succesfully and can be removed from that ring buffer?"
Both jetd and peer exchange the number of received / send message in the "config.resume" request/response. Both sides must resend eventually missed messages to the other party. The messages are dropped when new ones are send. So once started, the history buffer will grow to the max history size (which is 100 right now) and afterwards each send will drop the first message(s) and append the new ones at the end.

[mloy]

ok, if in normal operation (without loss of connection), we will use up the whole ring buffer and simply overwrite the oldest one.

[mloy]

concerning your test: I thought, the peer resumes against a new started jetd. Which should be possible too.