<div dir="ltr">x.25 provides a network service which is modelled as a non multiplexed, in-order loss-less, flow controlled packet delivery which is known as a "virtual" circuit - in fact, from the end host perspective, that looks very much like the service that a stream socket gives except that you need a multiplexing layer if you want multiple host associations...(i.e. iso tp0)<div>
<br></div><div style>inside the network, you do NOT have to preserve e2e packet ordering or reliability (i.e. you don't HAVE to do hop by hop ordering, loss recovery or flow control, although layer 2 flow control can help with the latter micro-protocol part of the X.25 service) - some implemenations of X.25 actually did a datagram network inside the network, and did end-to-end protocol work (strictly. NIC-to-NIC) to fix up missing packets and ordering etc...</div>
<div style><br></div><div style>most x.25 switches, tho, did do op-by-hop work, which made them cumbersome, slow, expensive, and also, remember back in the 1970s, people wrote a lot of code in very low level languages (macro 11, various uglier assembers...later on perhaps C) which made software incredibly hard to get right so having a lot of complex protocol code in a switch in the net was a v. bad idea then (nowadays you might get away with it, hence SDN/Openflow and the proliferation of middle boxen- not all there for bad reasons)...</div>
<div style><br></div><div style>note the model of "end2end" being NIC-to-NIC (rather than host to host) means that you don't get real e2e reliability out of X.25 since the semantics are (as per telephone semantics) delivery to the "socket on the wall" not to the ear of the human (i.e. a phone with a broken mike&speaker, or a host that has errorered memory ) </div>
<div style><br></div><div style>note this is not especialyl bad since TCP (when used by an app) delivers data to the socket queue - if the app fails to write it to disk (or render to screen) correctly, TCP can't know</div>
<div style><br></div><div style>(of course, the person holding the phone handset might be deaf, dumb or not speak the same language as the speaker at the other end:)</div><div style><br></div><div style>hence the semantics of ends are in the eye of the beholder imho</div>
<div style><br></div><div style><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Apr 26, 2013 at 5:01 AM, Detlef Bosau <span dir="ltr"><<a href="mailto:detlef.bosau@web.de" target="_blank">detlef.bosau@web.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Am <a href="tel:26.04.2013%2003" value="+12604201303" target="_blank">26.04.2013 03</a>:00, schrieb <a href="mailto:l.wood@surrey.ac.uk" target="_blank">l.wood@surrey.ac.uk</a>:<div class="im">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On the other hand: Do you know a current technology which is actually<br>
being used that does not use Ethertypes?<br>
</blockquote>
CANbus, SpaceWire, CCSDS, RapidIO, (A)X.25...<br>
</blockquote>
<br></div>
Oh, yes :-)<br>
<br>
I'm sorry about that...<br>
<br>
Additional question: Can you tell me which car uses TCP over CANbus, e.g. to control his lamps? ;-)<br>
<br>
<br>
But you made an important point: My view on this matter is too simplistic.<div class="im"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
But you can always layer (Cisco) HDLC or HDLC/ Frame Relay across any<br>
of these to get an Ethertype. Or lobby SpaceWire to put a value in<br>
their single-byte not-an-Ethertype field.<br>
</blockquote>
<br></div>
At least we have do agree on talking about "packet switching networks" in a quite narrow sense here, when it comes to Ethertypes.<br>
<br>
E.g. X.25 to my understanding is circuit switched. The packet switching view is mounted upon the top ;-) The same holds true for Frame Relay in a sense, however in FR the whole packets are switched IIRC and not subdivided into smaller pieces.<br>
<br>
However, this is in fact a discussion of implementation issues.<div class="im"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
(The CCSDS community finds the thought of layering HDLC over CCSDS<br>
especially abhorrent, because it cuts down their custom engineering,<br>
and any layering or modularity is considered to be inefficiency.)<br>
</blockquote>
<br></div>
At least, it is not a "holy cow". Layers should assist network design. And not the other way round.<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
<br>
<br>
</blockquote>
<br>
</blockquote></div><br></div>