Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!ucsd!ucbvax!FTP.COM!jbvb
From: jbvb@FTP.COM (James B. Van Bokkelen)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Reliable Datagram ??? Protocols
Message-ID: <9010231522.AA18327@ftp.com>
Date: 23 Oct 90 15:22:37 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: jbvb@ftp.com
Organization: The Internet
Lines: 28


    ....
    Finally, TCP as is will send many datagrams if you present more than a
    packet-sizes worth of data.  For a datagram oriented system, you would
    force it to send a fragmented IP packets instead (and the maximum
    segment size would have a slightly different meaning.)

Given my druthers, I'd much rather make message boundaries independent
of IP datagrams, because deliberate fragmentation is EEEVIIILLL!!!.  Also,
you'll never hear the end of "why are records limited to 65Kb" and "why
can't I use records bigger than 8Kb on my FooNix system"?

  If you're willing to re-implement everywhere
    If you're willing to settle for 16 bits of record length
      Do something really gross with the Urgent pointer and unused bits in the
      TCP header.
    Else
      Define a new TCP Record Option as: opt_type, opt_len followed by 
      (opt_len - 2)/2 "start of record offsets within this segment".
  Else
    Define a formal "Record-Oriented TCP Extension" which uses header/length
    and let the applications that want it use it.  If enough of them do so,
    someone will move support into a library, and then someone else will put
    it in the kernel.  You could even use ISO Session and get ASN.1 data
    abstraction in the ?bargain?

James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901