On Tue May 19 2009, Dave Thompson wrote: > > From: owner-openssl-us...@openssl.org On Behalf Of Ger Hobbelt > > Sent: Monday, 18 May, 2009 13:04 > - - - snip - - - > > > > c) the 'guaranteed delivery' I mentioned before: VMS offers > > this as a message-based protocol, but you can easily convert > > that into becoming a stream protocol by cutting the stream > > into messages and transfer them. How does it work? Well, TCP > > is connection-based, so once you loose the connection (for > > whatever reason: network failure or > > otherwise) you're done. > > VMS actually queues your messages (data chunks if you want to > > play stream over message protocol) and each message is > > potentially held in store indefinitely, until message from > > the receiver comes back that, yes, we got this one. This > > includes all the measures above: connection re-establishment > > upon failure to deliver (i.e. retry mechanisms at both > > message and node visibility levels), etc. It's been too long, > > but I seem to recall it also had options where you actually > > could request TCP-like behaviour: both in-order message > > reception and non-duplication. But my brain may be playing > > tricks on me there. > > > VMS may be the only place this was _in the OS_, I'm not sure, > but the same functionality has been created by many others. >
Unless you count Linux. ;) Linux supports (a partial) TIPC implementation in the kernels since 2.6.16 - Also in VxWorks, Solaris and OpenSolaris - http://tipc.sourceforge.net/ That is a "guaranteed delievery" transaction oriented protocol. It (or its predecessors) used for decades in the communications industry. Not only for machine control and administration but also for the billing data - - That example is (basicly) - Only the machine connected to the originator of a telephone call "knows" who should get the bill - - Only the machine connected to the called party "knows" how long the call lasted (from answer to disconnect) - - Plus, neither machine does the actual accounting - that's somewhere else - - So you have two "chunks" of information, in two different places, that must get combined and sent to a third place, mistakes and lost data are not an option. You had better believe that the telephone companies want to collect for every single one of the hundreds of millions of telephone calls made every day! (How many telephone calls have you made in your lifetime you where not billed for? One? Two?) And just like TCP, TIPC does not "care" what the data payload is, you can send an encrypted payload if you want to. ;) Mike ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
