26 Nov
2022
26 Nov
'22
7:27 p.m.
On Nov 26, 2022, at 11:49 AM, Johnny Billquist
<bqt(a)softjar.se> wrote:
On 2022-11-26 17:10, Paul Koning wrote:
Well. I wouldn't call it a design error in TCP. It a different model, and sometimes
one model is better than the other for the specific problem one wants to solve. That
don't mean either model is any kind of design error.
I call it a design error because a large number of higher layer protocols is forced to
work around this property, reinventing packet framing over and over. The reality is that
a whole lot of applications need packet semantics.
On Nov
25, 2022, at 6:47 PM, Johnny Billquist <bqt(a)softjar.se> wrote:
There is, as far as I know, no equivalent to push, since in DECnet, connections are never
handled as a stream of bytes, but as packets, and delivery is always immediate, and the
sending side is directly informed about the receiver actually receiving the packet.
It's essentially much more synchronous than TCP/IP. DECnet don't even necessarily
buffer on the sending side. At least with RSX, transmits goes directly from the task out
on the wire. And the send is only flagged complete when the receiving side have received
it. But on receiving side it might be in an internal buffer and not actually delivered to
the recipient task.
But I'm sure Paul remember more details.
However, one thing you do have in DECnet, which TCP/IP don't really do well, is that
you can send out of bounds, urgent data in DECnet.
Indeed, DECnet is a packet
service rather than a stream service -- that was the one major design error in TCP. And
there is no such thing as a "push flag". I don't know why there is in TCP,
for that matter. But the fact that in the IP world, there is no really
reliable, packet based protocol is a bit of a problem, because people often make erroneous
assumptions about TCP in this area. And the push function in TCP have a good reason for
existing. I would assume you knew that.
But yeah, TCP is very different than anything DECnet.
I've never seen anything in TCP that uses push. And I certainly can't imagine why
it would be a protocol bit; at the most it makes sense as an API option. (I do know about
the Nagle flag, but that's a mode not a transmit flag).
Indeed the lack of packet protocol is a major pain. Applications have to do it, and they
have to allow for packet boundaries to appear in arbitrary spots. I've worked on
protocol design (iSCSI) and implementation (iSCSI, NSF). On the one hand, those
implementations want to optimize what you hope is the common case, which is that packet
boundaries land on TCP message boundaries. On the other hand, the code isn't allowed
to assume that, it can only at most make that the more-efficient case. Walking through
protocol parsing code that's infested with "mbuf pull-up" calls to ensure
that the next foo bytes are available, and comparing that with the utter simplicity of
protocol parsing given a packet-oriented transport protocol makes me feel quite justified
to call this a design error and not merely a different but equally valid choice.
It's interesting that when the IP community designed a new transport, they made it
packet oriented. Unfortunately that transport (SCTP) hasn't seen wide adoption.
paul