Path: utzoo!attcan!uunet!know!cs.utexas.edu!sun-barr!olivea!oliveb!amdahl!rtech!wrs!hwajin
From: hwajin@wrs.com (Hwa Jin Bae)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Reliable Datagram ??? Protocols
Message-ID: <1273@wrs.wrs.com>
Date: 24 Oct 90 18:38:14 GMT
References: <9010231522.AA18327@ftp.com> <9010231706.AA25446@hogg.cc.uoregon.edu>
Sender: newsmgr@wrs.COM
Organization: Wind River Systems, Inc.
Lines: 31
Nntp-Posting-Host: daahoud

In article <9010231706.AA25446@hogg.cc.uoregon.edu> jqj@HOGG.CC.UOREGON.EDU writes:
>As an aside, 4.2bsd included Eric Cooper's courier compiler that implemented a
>Xerox SPP-like protocol over TCP (message boundaries and message types are 
>needed to implement the semantics of Courier).  As I recall, Eric just used
>a simple counted string approach, where messages could span multiple strings
>and end was delimited by an EOM bit in the message header, totally ignoring IP
>packet boundaries, PUSHes, etc. (you have to guarantee a PUSH after the EOM,
>I suppose).  Worked just fine if what you wanted was packet boundaries on TCP;
>no changes to TCP needed.

pretty much the same thing is done with sun rpc over tcp.  the following
is from sunrpc 4.0 release:

/*
 * xdr_rec.c, Implements TCP/IP based XDR streams with a "record marking"
 * layer above tcp (for rpc's use).
 *
 * These routines interface XDRSTREAMS to a tcp/ip connection.
 * There is a record marking layer between the xdr stream
 * and the tcp transport level.  A record is composed on one or more
 * record fragments.  A record fragment is a thirty-two bit header followed
 * by n bytes of data, where n is contained in the header.  The header
 * is represented as a htonl(u_long).  Thegh order bit encodes
 * whether or not the fragment is the last fragment of the record
 * (1 => fragment is last, 0 => more fragments to follow.
 * The other 31 bits encode the byte length of the fragment.
 */


-- 
hwajin@wrs.com