On Jan 29, 2013, at 2:02 PM, Johnny Billquist wrote:
...
Protocol wise, you could (I guess) just decide to append a CR+LF to each record sent, and
then strip those off at the receiving side before processing the data. But that is a
protocol change, as these would need to be explicitly added and removed inside the packets
sent in DECnet. Also, I guess each packet would be a full line, although doing data
merging of packets on the receiving side to get lines could also be done.
Well, actually, http already specifies the CF+LF on each record. The issue is the implicit
extra information received by doing packets instead of a stream, but you could just ignore
the record metadata, and look at it as a stream of bytes. It does, however, still force
you to define that this is how http should be done on top of DECnet, which today is not
"defined".
I think you're making this more complicated than it needs to be. DECnet has SDU
(message) boundaries, TCP does not. So TCP based protocols do not use message
boundaries, they are byte streams. If you want to carry a TCP-origin protocol over
DECnet, put the stream into DECnet messages without any regard to message boundaries
(other than any size limits). For received messages, ignore the message boundaries.
I think that's basically what a stream mode DECnet socket on Ultrix is defined to do.
So I'm basically saying that the mapping of http onto DECnet is "use stream
mode, object number 80" -- that's basically the whole description.
paul