Envoy source and availability

[clark]

Hi all,

As I've been getting back into Amiga, I've been using Envoy a lot in my network.   It's really useful! 

Does anyone know who owns the rights to Envoy and if they'd be willing to either sell them or release it to the public?  It's a great piece of software, but it needs some updating and TLC.

I tried to e-mail Heinz Wrobel who made the last update in 2004, but I never got a response.  Not even sure if the e-mail is still valid or if he's even still alive.

Of course, you can't buy it anymore, and the currently available pirated/cracked copies have a broken installation script.  I've taken a stab at writing a new one with a little script that combines the pirated ADFs + the last Envoy 3.1 update into a working installation bundle.  That's available here:  https://github.com/xlark/EnvoyInstall.  If anyone is interested.

I'd love to do more, but without the source code and distribution rights, I'm kind of hamstrung.

Thanks,

-Clark

[NinjaCyborg]

Heinz Wrobel still owns it. Multiple people have asked him over the years if he would sell it or release it and he always says no. Just another stubborn butthurt bastard like all the others in Amiga land. Shame, as Envoy was a lovely piece of software for the time.

[kolla]

It’s old and hackish anyways, why not create something better from scratch? Start with concepts of what you wish to accomplish (is printer sharing still imprtant? is not using tcp/ip still a thing?) and then draft some protocols for how to achieve what you want, and then try to implement them, one after the other.

[Hans_]

What about NetFS?

I have plans to write my own rl=https://keasigmadelta.com/zitafs-aos]network drive system[/url]. Sadly, I've had to put it aside for now.

Hans

[NinjaCyborg]

I love Envoy. Even if when it was new it was still a bit behind the curve of AppleTalk and Windows for Workgroups. But it's of that era - a generation where people still used proprietary transport layer protocols instead of only TCP and UDP. At the same time it was still IP based and therefore could share layer 3 with other stacks without clashing with each other. Nothing hackish about it at all.

I loved how well designed it was for the Amiga architecture. Services weren't daemons in the unix sense, instead, like all things amiga, they were shared libraries. There are same great examples of services that extend it's functionality on aminet, like the conf and talk services (source code available too).

It's correct to say that today in 2024 we would likely just use TCP/IP based services, and similarly that no one needs a LAN printer server - chances are any modern printer is its own server or accepts direct wifi print jobs, while cloud drives replaced peer to peer file sharing.

It's a shame Heinz is such a prick about making it available one way or another.

[olsen]

It’s old and hackish anyways.

It is old, but it is not that terrible. The important part which Envoy is built upon (nipc.library) has not aged gracefully, but Envoy 2.x and 3.1 have improved it. Its original limitations did not go away, though. Just like a TCP/IP stack, Envoy assumes it has complete ownership of the configured NICs and it will not play nice with others ("my way or the highway"). I think that this could be resolved by implementing an nipc.library which delegates all the UDP traffic wrangling to bsdsocket.library (it could happen). The "small catch" being that the modern Envoy protocols are wholly undocumented. Envoy 1.6 (from 1994) may not be interoperable with the more recent versions.

I still think the Envoy architecture is a pretty sweet design, but I do wonder how well the "reliable datagram protocol" of 1992 fares today. There's no documentation on its origins, let alone if there's any relation to the other n+1 curiously named "reliable datagram protocol" versions of that era. Remembering how quickly Envoy could freeze in a 1993 10BASE2 LAN, I reckon there's still work to be done to research how resilient the protocol really is. The members of the Amiga networking group were either reassigned or dismissed before Envoy could have matured.

Customary gratuitous rant which can be safely ignored: Envoy is not a file sharing or printer sharing solution. These services merely build upon the underlying reliable UDP protocol which nipc.library handles. Envoy is a platform which provides limited authentication and security (in 1992 everything was so simple), auto-configuring peer-to-peer networking without a central authority and enable data exchange between the clients. You could build distributed computing applications using that platform.

[kolla]

At the same time it was still IP based and therefore could share layer 3 with other stacks without clashing with each other. Nothing hackish about it at all.

Its original limitations did not go away, though. Just like a TCP/IP stack, Envoy assumes it has complete ownership of the configured NICs and it will not play nice with others ("my way or the highway").

So, which is it? "share layer 3 with other stacks without clashing" or "not play nice with others"?

One quite profound "clash" that I recall, is that of what UID 0 is.

[pVC]

What about NetFS?

NetFS Revised is a lovely piece of software for Amiga compatible filesystem and ARexx port sharing.

Here's a recent video how it works:
https://www.youtube.com/watch?v=SirKvJ03EnM

[kolla]

NetFS Revised is a lovely piece of software for Amiga compatible filesystem and ARexx port sharing.

I have an issue with client systems resetting/crashing when remote file share server reboots.
(But it seems to only happen when Workbench is loaded?)

Many years ago, I briefly started implementing the netfs protocol in python, with the goal of having a lighter alternative to smb and nfs for sharing file system to Amiga from non-amiga systems... but that project got lost in time.

[olsen]

So, which is it? "share layer 3 with other stacks without clashing" or "not play nice with others"?

One quite profound "clash" that I recall, is that of what UID 0 is.

The Envoy version for which I saw the source code talks directly to the SANA-II device driver. This is a problem because Envoy assumes that every IP or ARP frame which is transmitted is intended for its use. If a TCP/IP stack on the same machine uses the same SANA-II device driver, Envoy and the TCP/IP stack will grab the next available frame, being unable to check first if it was intended for them.

While you could make use of the SANA-II S2_PacketFilter option to figure out if the source or destination port number is 376 in the IP frame, the original Envoy did not support this option (this was added with Envoy 2.0, if memory serves). The bigger problem are the ARP frames. ARP replies will get read by Envoy or the TCP/IP stack, whoever gets lucky first. The S2_PacketFilter option is no help here either, since the SANA-II device has to offer each frame to every client until one says "it's mine". The filter works well for unicast, but for ARP replies which are broadcast there could be unexpected behaviour, such as the SANA-II driver not implementing the S2_PacketFilter option correctly.

Hiking the Envoy UDP traffic to how the TCP/IP stack does this would solve this overlap in responsibilities. Right now I don't see much of an alternative.

[kolla]

So are we approaching “hackish” yet?

[NinjaCyborg]

@kolla

You seem to be unable to differentiate between versions 1, 2 and 3. Olsen is talking about version 1. Perhaps you have reading comprehension issues. I would see a doctor if I were you.

[olsen]

So are we approaching “hackish” yet?

As I wrote, there is no wiggle room for changes to be made in how Envoy deals with SANA-II devices shared by another IP protocol stack (could be the Oxxi ACS client, could be AmiTCP) when broadcast ARP replies enter the picture. Whoever queued the first S2_READ command will deprive the other stack from learning about the ARP reply's message.

In my opinion, a TCP/IP stack as the means to handle ARP and UDP for Envoy would be in the best position to solve this problem because we still have more than one such stack which is still being maintained and developed. It could also deal well with SANA-II devices which do not implement the S2_PacketFilter option, or which implement it incorrectly.

Because the ownership of the Envoy code as it was in 1992-1994 and beyond is complex, I'm just blowing soap bubbles here   Could be that there will come a time when Envoy might make a comeback and one hypothetical way to solve the IP and ARP frame sharing issue might come in handy.

[olsen]

@kolla

You seem to be unable to differentiate between versions 1, 2 and 3. Olsen is talking about version 1. Perhaps you have reading comprehension issues. I would see a doctor if I were you.

As far as I know, Envoy versions 2 and 3 still cannot share the same SANA-II device with AmiTCP, INet-225, Miami, Roadshow, etc. unless you change the frame types for IP and ARP from 2048 and 2054, respectively, to something else.

While versions 2 and 3 are improvements over their precursors, it should not be necessary to tinker with the frame types. There is little harm in this, though, e.g. 2049 and 2055 are presently tagged as "unavailable" or "private" (see https://standards-oui.ieee.org/ethertype/eth.txt).

I would like to see what Envoy does (or attempts to do) implemented robustly. We have nothing comparable to it today, as far as I can tell. What we have is no longer being sold, maintained or developed and there is no replacement for it.

[kolla]

Perhaps you have reading comprehension issues.

Or maybe you have such issues? As olsen points out, there are "clashes" that needs to be resorted manually for Envoy and TCP/IP stacks to work well on same SANA-II device. This was still needed last time I tried latest version of Envoy (which I admit is like many years ago now). This is what I meant with "hackish".

Here i from the 3.1 update on aminet (http://aminet.net/package/comm/net/Envoy3_1Update)

If you are using a TCP/IP protocol stack like AS225, INet-225, Miami, or AmiTCP, you need to have SANA-II networking devices that support multiple protocol stacks. Most devices do. You also should not use the same IP or ARP numbers for Envoy that you are using for TCP/IP. Unless you are specifying your own numbers during the configuration, this Installation will automatically increase the common defaults to avoid conflicts.

(It is also worth nothing that this update has binary patch for a2065.device and ariadne_ii.device - hm, why is that)