Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!usc!sdsu!ucsd!brian
From: brian@ucsd.Edu (Brian Kantor)
Newsgroups: comp.protocols.tcp-ip
Subject: Protocol Design issue
Message-ID: <10439@ucsd.Edu>
Date: 13 Dec 89 14:36:50 GMT
Organization: The Avant-Garde of the Now, Ltd.
Lines: 25

I'm currently designing yet another protocol to sit on top of a
reliable stream such as the TCP, but I'm not sure about one issue:

We have, as part of the various transactions that take place during the
lifetime of a connection, to transfer binary data.  Even with differing
machine architectures, the byte-ness of the data must be preserved
(i.e., it's still N bytes whether you store 4 or 6 per machine word).

It seems to me the best way to do this is by doing it in-band, that is,
sending a plaintext header with a byte-count, followed by that exact
number of bytes in literal mode.  This requires an accurate byte
counting at the sender and recipient, but that isn't a very difficult
thing to do, and it's not computationally expensive.

This is straightforward and relatively simple, and given the underlying
mechanism of an ordered reliable 8-bit stream, I don't see any
significant drawbacks.

All the other alternatives I've seen or dreamed up require either some
imbedded control characters with escaping, or else send the data
out-of-band (for example, FTP using a separate stream from the control
stream for file transmission).  I find both these ideas distasteful.

Are there any drawbacks to byte-counting that I've overlooked?
	- Brian