> reliable UDP protocol
You want a reliable *unreliable* datagram protocol protocol?
Sounds like something guaranteed to fail.
Everyone tries to reinvent TCP. Almost always they make something significantly worse. This is no exception.
I once worked at a company that made Parking Meters - and accepted credit cards at them. They sent their data over https, and had random issues with timeouts.
It turns out they would format their data in (very descriptive) XML, and discovered an excessively large file combined with an SSL handshake over crappy 2g connection took too long to transfer the data (it didn't help the programmers 'forgot' they hardcoded a timeout, so if the comms was just slow, it would throw a generic error and they blamed Apache for it).
In any case, the offshore dev team's solution was to create a UDP client/server protocol of their own.
It was working nicely when I left, and was PCI Compliant, but at that point we had no way to reliably monitor communications from the perspective of the meter because we (SysAdmins in charge of the backend systems) would have had to write proprietary code from non-existing documentation just to replicate what used to be a simple HTTP POST.
Some things look great, but aren't thought out all the way ...