<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>This is true, particular in the case where you want to know "end
of current stream" or end of file, which is meta-data that can not
be gotten from TCP.<br>
</p>
<p>In FTP, you know this for the current file if you are not holding
the data port open because the port is closed, giving you end of
file. Knowing end-of-file allows you to do some excellent
optimizations; real speed.</p>
<p>Paged file structures breaks all that because you don't know
end-of-file until the data stream tells you, which means large
reads can become problematic (I.E., you hang waiting for data).</p>
<p>Doing a send is fine because you don't need to care, but the
receiver has to decode the data stream on the fly instead of doing
a big slurp.</p>
<p>This is the reason I didn't get the Extended mode FTP server done
before MRC passed. All of the data handling code expected
synchronized meta-data to indicate end of file (I.E., port
closed). You can't do that with a port held open, even with a
push which may get swallowed. Urgent out of band data doesn't
work, either because it may come in before the end of the data
stream. Besides, that would break RFC959 compliance for 20's and
TENEX sites that use the BBN server and client.<br>
</p>
<blockquote type="cite"
cite="mid:050F0235-D57A-4BDA-946D-330748F214C1@comcast.net">
<hr width="100%" size="2">
<pre class="moz-quote-pre" wrap="">On 11/8/21 10:32 AM, Paul Koning wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">On Nov 8, 2021, at 10:13 AM, Johnny Billquist <a class="moz-txt-link-rfc2396E" href="mailto:bqt@softjar.se"><bqt@softjar.se></a> wrote:
On 2021-11-08 15:27, Paul Koning wrote:
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">On Nov 7, 2021, at 9:54 PM, Peter Lothberg <a class="moz-txt-link-rfc2396E" href="mailto:roll@stupi.com"><roll@stupi.com></a> wrote:
In the "old days" we did SMTP over DECnet, has anyone considered doing Telnet, FTP, HTTP etc over
DECnet transport?
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">I've thought about http over DECnet. That would be really easy. The obvious way to deal with any TCP-based protocol is just to send the byte streams over DECnet messages, in the same fashion as DECnet/Ultrix streaming mode DECnet sockets do. (Precisely how that works I don't remember.) In the case of HTTP, a natural simplification would be to send the entire header, in both directions, as a single message, with any data following in one or more additional messages.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
Streaming mode DECnet sockets would be interesting to learn something about.
Because otherwise the problem is really that DECnet is packet based, and not byte based like TCP. So there is potentially some problems with adapting TCP protocols for DECnet.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
Not really. Stream based protocols are protocols that do not rely on message boundaries -- more precisely, do not rely on boundaries being marked by lower layers. If you have a transport that does report message boundaries, and you want to carry a stream protocol, the simple answer is to ignore those boundaries.
The reason I'm interested in how Ultrix did streaming sockets is because of the question "when do you send the message". That's actually a question with TCP as well, which is why it has a "no delay" option. The trivial answer is "for each send() call to the socket, send that data as a complete NSP message". That would obviously work; the only question is whether something fancier is a useful optimization.
Actually, there might be one other question. Consider HTTP: if the server wants to send a file (say, a .jpg image) can it send the entire file as a single NSP message? From the DECnet architecture point of view, sure. Do DECnet implementations put some limit on the length of an NSP message? I don't know, except for RSTS which doesn't simply because it leaves segmentation and reassembly to the application.
The mismatch that's harder to deal with is an application that needs message boundaries, running over a transport that doesn't have these. The TCP/IP world is full of these, and in every instance the application protocol concocts an ad-hoc solution to this issue. Consider iSCSI and NFS as two examples, with different solutions (or multiple solutions, if you take the "markers" hack in iSCSI seriously).
paul
</pre>
</blockquote>
</body>
</html>