Envoy source and availability

[kolla]

commodities can give you something similar for GUI based applets

Commodities don't necessarily have GUI, what makes you think so?
AutoPoint, ClickToFront and NoCapsLock for example, don 't.

what's the use case? here's one - every time you want to use an external rexxport, you need to check if the port exists, and if it doesn't, run the host for that port, if you even know where to find it.

Not sure what you mean with "external rexxport", but if you mean an arexx port of a program, and your complaint is that you need to run the program to make the port available... yes, is that hard? What I hear is that you want the system itself to detect that something is trying to open an arbitrarily named arexx port, and then launch the software that's somehow is registered with this arbitrary port name... correct? The question becomes, how to detect what port is attempted, and how to ensure the right software is started so that something can answer on the port correctly before the client gives up. In principle you can have a script that listens to all the ports you have set up in a "servers" like file, and when something connects, it will shut down its port and launch the software so it can open the real port... however, the client may have become unhappy at this point, because of the port "hand over", or simply because launching the software may take too long.

Or you want to open on a named PUBSCREEN. But you're first to arrive, and the screen isn't open yet.

Well, there's a (badom-tish) commodity for that - MUI:PSI, it can do just this, and I am sure there are other pub screen handlers that do the same. Should the OS come with a pubscreen commodity handler built in? In my view - Absolutely! But certain OS developers didn't think it's worth wasting time on, as there are already third party tools for this.

[olsen]

But I don't see anything in the SANA-II docs to say that a driver shouldn't also offer a frame to other stacks if one stack's filter hook accepts the frame. So to me it seems more like a bug in the driver if Envoy interferes with another stack in this way, as it might be a valid case for multiple stacks to be interested in the same frame, and my interpretation of the docs is that a TRUE result from a stack's filter hook just means "yes, I'll take a copy of that", not "hands off, it's mine"

Except that the documentation does not go into detail how you should implement the filter on the driver's side. There exists exactly one officlal Commodore implementation of the "S2_PacketFilter" feature in the internal "slip.device", which features the version string "slip 38.1 (17.2.94)".

Correction, half an hour later: I reread the implementation's code and realized that I was looking at the wrong thing.

So, let's start over again how "slip.device" deals with the "S2_PacketFilter" feature.

When a new frame arrives, "slip.device" will offer a preview of the frame to every client which currently has a CMD_READ pending. If the client's hook code likes what it sees and returns a non-zero value, then the CMD_READ request's CopyToBuffer() callback will transfer a copy of the frame to the client and the CMD_READ command will be "terminated" by removing it from the queue, calling ReplyMsg() if the IOF_QUICK flag is not set. If the hook code returns zero, then the client will not receive a copy of the frame. "slip.device" walks through the list of clients which submitted CMD_READ commands until it has reached the end.

This means that every client gets asked if it wants to process the frame or not. Nobody can steal a frame. Every client receives a copy if it wants to.

If this is how it should work, it raises the question if every SANA-II driver out there that supports the "S2_PacketFilter" feature implements it correctly.

The Envoy 3.0 filter hook might just be a "victim" of SANA-II drivers not implementing the filter feature consistently.

[nbache]

For Envoy 3.0 the packet filter has the effect of stealing multicast/broadcast traffic from everybody. Reading the documentation and the implementation for the S2_PacketFilter hook feature, it is framed as an optimization, which it would have been if the client wouldn't have become the sole owner of the frame. Saying "no, it's not for me" to a frame is helpful, but saying "this looks interesting" ends up removing the frame has unexpected consequences. I wonder what purpose this behaviour could possibly have that makes sense?

Speed? It was created in another age with slow networks and slow computers, compared to today's world.

Best regards,

Niels

[ncafferkey]

The Envoy 3.0 filter hook might just be a "victim" of SANA-II drivers not implementing the filter feature consistently.

I'd put money on it However, cnet.device seems to do it properly (to take another random example that has source code available).

[olsen]

I'd put money on it However, cnet.device seems to do it properly (to take another random example that has source code available).

I checked and both ariadne.device and ariadne_ii.device do the right thing, too   Wish I could have said that for ppp-serial.device and ppp-ethernet.device, but I had last updated these in 2017 (time flies) and did not know any better at the time. "Luckily", ppp-serial.device and ppp-ethernet.device are typically "single client only".