Correspondents

Craig Latta Craig.Latta at NetJam.ORG
Mon Jan 11 09:54:41 UTC 1999


> > To avoid confusion with "protocol" in the traditional
> > Smalltalk sense, I'll use "IETF protocol" as a blanket term
> > for things like HTTP. "IETF" is of course the "Internet
> > Engineering Task Force", the specification coordination
> > body (http://www.ietf.org).
>
> How about "Network Protocol" ?  I think your framework is
> appropriate for implementing ITU and vendor proprietary
> protocols such as Lego Mindstorms...

	Good point. I thought of using "network protocol", but thought that would get confused with network *transport* protocols (e.g., TCP, UDP). But it should include more than just common protocols used on the Internet, and a simpler name would be nice. Perhaps "conversation protocol" or somesuch.

> > So far, "commands" are just Strings. E.g., 'GET' and
> > 'HEAD' from HTTP. All the popular protocol specifications
> > we've dealt with so far (see http://www.rfc-editor.org) use
> > simple ASCII. I'd like to do interesting things with distributed
> > objects later.
>
> How tough will it be to extend this?  I'm working on SNMP and
> it uses ASN.1 encoding ["abstract syntax notation", see e.g. 
> http://www.techapps.co.uk/asn1gloss.html].

	I don't think it would be tough at all. Specifications for ASN-based protocols are very clear, via their "encoding rules", about how to express fields as bits. NetStreams (and therefore Correspondents) can transmit raw bits. I hope I understood the question...

> Your framework seems to be very stream-oriented which is
> convenient for most of the IETF protocols. Have you
> given any thoughts to protocols that are "message-oriented"?
> By message-oriented, I mean ones that use UDP or use TCP
> with rigorous boundaries (imagine a TCP protocol that has a
> length field at the beginning and you don't know the length until
> you construct the message...).

	I've written correspondents for message-oriented protocols, but I never generalized support for them into the abstract classes. I'd construct a message in a local temporary stream, then do things like (stream nextPut: message size; nextPutAll: message contents). The correspondent protocols were too few in number and too disparate for a real pattern to emerge.

	By the way, a NetStream on a UDPSocket affords the use of stream protocol, even though the socket is packet-based. (You can still use packet-oriented messages, too.)

> It is sometimes handy to use a streaming protocol to construct
> the "network message". At other times it is handy to construct the 
> message field by field.  Transmission of the message would normally
> be under the (framework) users control.  In looking at your hierarchy,
> I suppose I could make these "network messages" be the basic
> object that is streamed by a protocol specific stream.  Does this
> sound right?

	Not quite... you just need to ensure that the network messages can appropriately print themselves as bits (or characters) on NetStreams (similar to the >>printOn: convention).


-C


--
Craig Latta
composer and computer scientist
craig.latta at netjam.org
www.netjam.org
latta at interval.com
Smalltalkers do: [:it | All with: Class, (And love: it)]





More information about the Squeak-dev mailing list