I released my library under the ASF 2.0 licence today. Keeping it short: it provides a thin reliable layer above the UDP protocol.
But see for yourself: http://www.jfastnet.com/
I’m open for criticism and would love to get feedback! 
took a quick glance at the githubs. looks very clean and fairly high level. thanks for sharing!
I don’t get it from looking at the front page info.
“The receiver of a message with reliable mode set to ACK_PACKET will send an acknowledge packet to the other end upon receipt of the message. As long as the sender of the prior mentioned message doesn’t receive an acknowledge packet it will keep resending the message.”
If the client DOES receive the packet the data is already old. The sender should never need to send even OLDER data back to the client. The server sends the newest data with respect to the last ACKed packet.
“But if a message with an id greater than expected is received, the receiver will stop processing the messages and send a RequestSeqIdsMessage to the other end. Processing will not continue until all required messages are received.”
Instead of writing: http://gafferongames.com/2015/09/12/is-it-just-me-or-is-networking-really-hard/
@Roquen: The two quotes you used are from two different modi. The ACK mode I implemented works simply by sending an acknowledgement of receipt. Client C, Server S.
C sends message to S. S receives message. S sends ACK to C. All good.
C sends message to S. Message gets lost. C sends message to S again. S receives message. S sends ACK to C. All good.
C sends message to S. S receives message. S sends ACK to C. ACK gets lost. C sends message to S again. S receives message, but discards it because it received the message already, but sends ACK again. C receives ACK. All good.
Second modus: Reliabale Sequence
C sends message with id 1 to S. S receives message. All good.
C sends message with id 2 to S. Message gets lost.
C sends message with id 3 to S. S receives message, but notices that it’s missing message id 2, so S sends a RequestSeqIdsMessage to C. C receives the message an resends message id 2. All good.
I hope that cleared things up.
[quote]If the client DOES receive the packet the data is already old. The sender should never need to send even OLDER data back to the client. The server sends the newest data with respect to the last ACKed packet.
[/quote]
It really depends on what you want to do. For the case you mention, simple unreliable sending would probably be the best fit. 
EDIT: I skimmed through the link you provided, because I don’t have a lot of time right now and I already read a lot from this blog and this guy. Yeah, message stacking with control data until the other end acknowledges a whole range of messages is a cool thing. It’s a feature I will take into account of adding. But for the time being the reliable sequence mode as it is right now works really good in real-life settings.
I understand what the contracts are. I’m asking “why”?
The “Acknowledge packet” contract you could say: chat messages.
The “Sequence number” contract you could say: live data-file updates (as in during game-play)
Both both of these examples one could argue should be different channels than game-state data transfer.
So why do it this way? What’s the use-case you envision? Having this kind of info on that front-page overview seems like a good idea.
[quote]So why do it this way? What’s the use-case you envision? Having this kind of info on that front-page overview seems like a good idea.
[/quote]
Ah ok, sorry! Now I get your point. Yeah, that’s a good idea. I must admit I haven’t spent much time on the documentation and frontpage until now. Thanks for your feedback, I’ll keep that in mind when reworking the page.