Re: [PATCH net-next] net: x25: Remove unimplemented X.25-over-LLC code stubs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]<

 



On Thu, Dec 10, 2020 at 1:14 AM David Laight <David.Laight@xxxxxxxxxx> wrote:
>
> > To me, LLC1 and LLC2 are to Ethernet what UDP and TCP are to IP
> > networks. I think we can use LLC1 and LLC2 wherever UDP and TCP can be
> > used, as long as we are in the same LAN and are willing to use MAC
> > addresses as the addresses.
>
> Except that you don't have any where near enough 'ports' so you need
> something to demultiplex messages to different applications.

Yes, LLC only has 256 "ports" compared to more than 60000 for UDP/TCP.

> We (ICL) always ran class 4 transport (which does error recovery)
> directly over LLC1 using MAC address (a NUL byte for the network layer).
> This requires a bridged network and globally unique MAC addresses.
> Sending out an LLC reflect packet to the broadcast MAC address used to
> generate a couple of thousand responses (many would get discarded
> because the bridges got overloaded).

Wow, You have a really big LAN!

> > X.25 layer 3 certainly can also run over LLC2.
>
> You don't need X.25 layer 3.
> X.25 layer 2 does error recovery over a point-to-point link.
> X.25 layer 3 does switching between machines.
> Class 2 transport does multiplexing over a reliable lower layer.
> So you normally need all three.

Yes, I was just saying X.25 layer 3 can run over any reliable
point-to-point links, including X.25 layer 2, LLC2 and TCP.

> However LLC2 gives you a reliable connection between two machines
> (selected by MAC address).
> So you should be able to run Class 2 transport (well one of its
> 4 variants!) directly over LL2.

Yes.

> The advantage over Class 4 transport over LLC1 is that there is
> only one set of retransmit buffers (etc) regardless of the number
> of connections.

Right. But nowadays we have big enough memories for many buffers, so
it may be preferable to make connections operate independent of each
other. This way one lost frame wouldn't affect all connections. This
is also why HTTP3 moved to QUIC instead of using TCP.

> But this is all 30 year old history...

Haha, we are talking about really old technologies.



[Index of Archives]     [Linux ACPI]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Photo]     [Yosemite Photos]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux