tpc@bnr-fos.UUCP (Tom Chmara) (05/29/89)
We've identified a requirement for a reliable communications mechanism within the UNIX environment, but can't accept the timeout restrictions for TCP (we did some cocktail-napkin math, and came up with something like 45s to detect that your destination isn't responding, and 6m to detect that he's gone away). As well, we may need HUNDREDS of connections from one process, and that sort of blows the old "32/64/80 connections per process" out of the water. According to the manual pages, UDP can drop, duplicate, and/or resequence packets without warning (sounds reasonable for datagram). Datagram offers us the opportunity to maintain our "HUNDREDS" of clients, but is particularly unfriendly, as we now have to maintain our OWN resequencing/retransmission mechanisms in the application. Does anyone know of any a) free b) $$ software which implements reliable datagram service, something like the SOCK_SEQPACKET (sequenced, reliable, two-way connection-based byte stream for fixed-length datagram) described in the literature? Something which isn't quite this reliable is also, obviously, worth investigating, as it's pretty much got to be better than this (we're looking at bloody stop-and-wait, right now...yes, we're desperate...) The software would ideally run in any HP/SUN/4.3 environment, but then, we can't have everything... Please email; I will post a summary in a few weeks' time... Thanks for your time... ---tpc--- -- I am sole owner of the above opinions. Licensing inquiries welcome. ------------------------------------------------------------------------ Tom Chmara UUCP: ..utgpu!bnr-vpa!bnr-fos!tpc BNR Ltd. BITNET: TPC@BNR.CA
tpc@bnr-fos.UUCP (Tom Chmara) (06/09/89)
In article <526@bnr-fos.UUCP> I asked... >Does anyone know of any > a) free > b) $$ >software which implements reliable datagram service, something like the > SOCK_SEQPACKET >(sequenced, reliable, two-way connection-based byte stream for fixed-length > datagram) >described in the literature? "DID WE GET LETTERS!?!" To summarize: - I asked for the wrong thing, though many people figured out what it was I wanted vs asked for. As Craig Partridge & jqj@hogg were so kind as to point out, with admirable restraint.. (jqj's words): "You asked about both RDP and sequenced packet protocols. 4.3BSD supports a sequenced packet protocol, SPP, in the XNS domain. A reliable SPP carries almost all of the baggage (except fragmentation/reassembly) that a TCP stream does i.e. is just as expensive. All it does is *in addition to providing a stream* provides information to the client on packet boundaries. Not what you want." What I WANTED was reliable datagrams. (Craig Partridge HAS a sequenced packet protocol: RDP, for those who might want it; contact him at craig@nnsc.nsf.net). - I heard about TWO reliable datagram protocols. One is eXpress Transfer Protocol (XTP). Rex Buddenberg (budden@manta.nosc.mil) described it as follows: "Not exactly free, and not exactly here yet either...but. Reliable datagram service isn't as easy as it sounds at first encounter. First, consider how TCP handles things: <description left out> Note that you've burned up 9 packets in order to get one packet through the system. Further, the data packet is the fourth one in line -- if latency is a concern (and in tactical applications it most definitely is), then you've eaten up a lot of overhead before you get real performance. What we are currently latched onto is eXpress Transfer Protocol. XTP allows the connection open, the data and the connection close to all go in the very first packet. So you get out with a grand total of 3 packets for guaranteed delivery; and the data goes in packet #1 now. XTP is being build by Protocol Engines Inc in Santa Barbara. They intend to embed it in a chipset in a year or so. In the meantime, some beta sites are running C versions. If you are looking for a 'today' answer this isn't it, but next year..." I heard from many people about the second reliable datagram protocol: Guy Middleton won with being first here; jqj@hogg, dave crocker (dcrocker@ahwahnee.stanford.edu) also replied. Sorry if I missed anyone... The protocol is VMTP ( Versatile Message Transport Protocol) and is described by RFC 1045. The abstract for RFC 1045 describes VMTP as "a transport protocol specifically designed to support the transaction model of communication, as exemplified by remote procedure call (RPC). The full function of VMTP, including support for security, real-time, asynchronous message exchanges, streaming, multicast and idempotency, provides a rich selection to the VMTP user level. Subsettability allows the VMTP module for particular clients and servers to be specialized and simplified to the services actually required." VMTP is layered atop IP; i.e. is a peer protocol to UDP and TCP. The VMTP README file for the second release notes that VMTP "is available for "Sun-3, Sun-4, Vax, and DEC mips architecture machines" VMTP is available from Stanford University Distributed Systems Group. If you wish to be added to the VMTP mailing list, drop a line to vmtp-ip-request@gregorio.stanford.edu. Postings to the mailing list are sent to vmtp-ip@gregorio.stanford.edu. I do not know any details regarding licensing for educational or commercial use. Thanks to all who responded; if I've missed your name in the above credits, please accept my abject apologies. Response to my question was as always quick, insightful, and clear. Thanks again. ---tpc--- -- I am sole owner of the above opinions. Licensing inquiries welcome. ------------------------------------------------------------------------ Tom Chmara UUCP: ..utgpu!bnr-vpa!bnr-fos!tpc BNR Ltd. BITNET: TPC@BNR.CA
dcrocker@AHWAHNEE.STANFORD.EDU (Dave Crocker) (06/10/89)
Your quotation of Rex Buddenberg's comment that TCP requires a minimum of 9 packets to deliver one did not ring true, so I did a little background querying. At the moment, the contest is between 3 and 5 packets, but certainly not 5. (Just is case anyone thinks that this note is trying to suggest that a reliable datagram protocol is not a good idea, don't. It's only that 9 is such a high number, it makes TCP look unreasonable.) The theory that suggests 3 packets says that the originator sends a packet that contains an open(SYN), close(FIN), and the data. The receiver returns a packet that contains a a SYN/FIN/ACK, and the original host then returns an ACK. (3-way handshake.) Dave