SANA-II files for development in SAS/C?

[olsen]

Did these go past proposal and discussion to be ratified into the spec?

They represent the current state of the technology. It's not as if we had a board of officers charged with reviewing and casting proposals into a common specification. With SANA-II it's more like a cheap version of the RFC approval process: you work on your proposal, talk it over with your peers, and then you publish it. The documentation should be good enough to write code for it, and to leave no obvious questions unanswered. Better still, publish example code for your proposal.

[olsen]

Well, if you bypass the IP stack you're going to have to implement quite a bit of stuff, for instance ARP daemon. Unless of course if you're going to send the packets to MAC address rather than IP address...

Careful with the ARP packets: due to how many, if not most SANA-II drivers work, multiple clients trying to read incoming packets will interfere with one another. Typically, the first client which manages to receive a packet it asked for will prevent that packet from reaching all other readers.

This not not how it is supposed to happen. A SANA-II driver must offer the same packet to all readers and must not assume that if the first client accepts it the packet has been dealt with.

Note that this issue is not limited to ARP packets. IP packets may get "lost" in the same manner.

[olsen]

Sure, but as already mentioned anything SANA2 R2 compliant must support multiple readers. All my drivers do at least.

It would be nice if all SANA-II R2 compliant drivers actually worked correctly, but you can only hope. For example, "a2065.device", last updated by Commodore in around 1993/1994, will make the first reader of a packet "consume" that packet, denying other readers access to it. It's possible that other drivers of the same age do the same (I haven't checked "ariadne.device", but it might have this "bug", too).

[olsen]

They're not R2 compliant then. I know that even the SANA2 example code has this bug. Anyhoo, I'd still argue that most new drivers handle this correctly.

I would hope so, but the number of reference driver implementations is so low that the poor example of the slip/cslip driver in the SANA-II SDK of old is bound to lead developers to implement the same bugs in their code. I know that I did in my ppp-serial.device and ppp-ethernet.device drivers, and it took me a while to notice that I was doing something wrong.

There are more problems than this multireader issue however, in many cases things will go wrong anyway. For instance if you try to perform TCP traffic with two readers, if the "wrong" reader gets a SYN|ACK the reader will RST the connection.

Interesting point. I think that it may not be quite so risky that a connection will drop. The greater risk may be in that a three-way handshake during connection establishment and tear-down may get derailed.

It takes an effort to tear down a connection, especially by mistake. Accidentally kicking a three-way handshake on the shin, so to speak, might be more easily triggered.