<div dir="ltr"><div>I certainly don't want to go against the groove here, so doing nothing is fine by me. However it might be worth mentioning what brought about this submission in the first place.</div><div><br></div><div>I've been interested in getting Squeak et al to play nice with some of the new decentralized web standards that are emerging. One of these is a set of protocols called <a href="http://libp2p.io">libp2p</a> (not really a library but a set of standards), which is used by interesting networks such as Secure Scuttlebutt. It turns out libp2p and perhaps some other adjacent technologies rely on another standard called <a href="https://github.com/multiformats/multiaddr">Multiaddr</a>, which is a format for describing various network configurations that has both a string and packed bytes representation. It was during some exploring with multiaddr that I learned the standard NetNameResolver wasn't quite up to dealing with ipv6 addresses in-image.</div><div><br></div><div>It could be that it's just not worth implementing libp2p in Squeak. Or perhaps the fundamentals would need to be a VM plugin, but that seems a bit excessive to me.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jul 27, 2021 at 7:42 PM David T. Lewis <<a href="mailto:lewis@mail.msen.com">lewis@mail.msen.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Eric,<br>
<br>
To be honest I'm not sure what we should do. Maybe nothing. Like you,<br>
I am a reader of the code, not a writer. But after poking around with<br>
it (thanks in good measure to your inbox submission), my sense of it<br>
is that the design intent of the network resolver primitives was for<br>
socket information to be opaque (not directly meaningful in the image,<br>
and typically in practice being a byte copy of some data structure<br>
in the VM plugins). We see similar things throughout the file and<br>
and socket plugins.<br>
<br>
I have personally abused the "opaque" fileID handle in our file streams<br>
when I implemented OSProcess/CommandShell, and I remember being sternly<br>
lectured by Andreas Raab on that topic. He was not wrong, and IMHO<br>
neither was I, but I don't know the right balance here.<br>
<br>
I think that Andreas and Ian Piumarta were working together on the<br>
socket plugin and network resolver primitives, and I think that their<br>
underlying philosophy was that security and reliability were important,<br>
and therefore that handles on data structures in the VM (such as file<br>
and socket information data structures) should be treated as meaningless<br>
bags of bytes on the image side. VM plugins can handle this safely and<br>
reliably, but the VM tends to get confused when people like you and me<br>
mess around with the internals of the opaque data structure bytes.<br>
<br>
In fact, I also remember Andreas proposing a scheme (never implemented)<br>
to replace our current "bag of bytes" handles for socket and file data<br>
structures with integer handles that were guaranteed to make the data<br>
structure internals invisible to the image. I was not personally in<br>
favor of that (because it would have made OSProcess infeasible) but<br>
I do understand the motivation.<br>
<br>
Dave<br>
<br>
<br>
On Tue, Jul 27, 2021 at 06:40:40PM -0400, Eric Gade wrote:<br>
> Hi Dave,<br>
> <br>
> Thanks, those examples give me a better understanding of what's going on<br>
> here. What do you think we should do? It seems that SocketAddress >><br>
> #asByteArray also assumes IPv4, so I could update that to use the new<br>
> NetNameResolver methods too. But is there anything else? Should<br>
> #stringFromIPv6Address: and #addressFromIPv6String be updated to respond<br>
> with appropriately configured SocketAddress instances, rather than plain<br>
> ByteArrays?<br>
> <br>
> On Sun, Jul 25, 2021 at 6:36 PM David T. Lewis <<a href="mailto:lewis@mail.msen.com" target="_blank">lewis@mail.msen.com</a>> wrote:<br>
> <br>
> > On Tue, Jul 20, 2021 at 06:16:51PM +0000, <a href="mailto:commits@source.squeak.org" target="_blank">commits@source.squeak.org</a> wrote:<br>
> > > A new version of Network was added to project The Inbox:<br>
> > > <a href="http://source.squeak.org/inbox/Network-EG.246.mcz" rel="noreferrer" target="_blank">http://source.squeak.org/inbox/Network-EG.246.mcz</a><br>
> > ><br>
> > > ==================== Summary ====================<br>
> > ><br>
> > > Name: Network-EG.246<br>
> > > Author: EG<br>
> > > Time: 20 July 2021, 2:16:51.031725 pm<br>
> > > UUID: 286844ab-38ff-4f7d-97a4-37d69eda41e5<br>
> > > Ancestors: Network-ct.245<br>
> > ><br>
> > > Adding methods and helpers for:<br>
> > > 1. Converting from an IPv6 string to an IPv6 ByteArray;<br>
> > > 2. Converting from an IPv6 ByteArray to a valid IPv6 string.<br>
> > ><br>
> > > Note that the complexity here is mostly taken up in dealing with the IPv6<br>
> > > "feature" of compressing the longest consecutive series of 0 values to<br>
> > > the string '::'.<br>
> > ><br>
> > > I have also updated the plain #addressFromString: and #stringFromAddress:<br>
> > > methods to first try and see if they are dealing with what appears to<br>
> > > be and IPv6 string/bytes and to call the IPv6 specialized versions of<br>
> > > the method if so.<br>
> > ><br>
> ><br>
> > Interesting work, thanks. Here are some workspace doIts that illustrate<br>
> > how the raw address bytes related to the socket address information<br>
> > that is managed in the SocketPlugin in the VM. I used '<a href="http://google.com" rel="noreferrer" target="_blank">google.com</a>' as<br>
> > an example, because the resolver on my computer gives both an IPv4 and<br>
> > IPv6 address listing. I am on a 64-bit machine, and the socketAddressBytes<br>
> > below would be different on a 32-bit machine.<br>
> ><br>
> > google := NetNameResolver addressesForName: '<a href="http://google.com" rel="noreferrer" target="_blank">google.com</a>'.<br>
> > googleIPV6 := google second. "==> 2607:f8b0:4009:809::200e(<br>
> > <a href="http://ord37s33-in-x0e.1e100.net" rel="noreferrer" target="_blank">ord37s33-in-x0e.1e100.net</a>),0(0)-inet6-stream-tcp "<br>
> > socketAddress := googleIPV6 socketAddress. "==> 2607:f8b0:4009:809::200e(<br>
> > <a href="http://ord37s33-in-x0e.1e100.net" rel="noreferrer" target="_blank">ord37s33-in-x0e.1e100.net</a>),0(0) "<br>
> > socketAddress size. "==> 36 "<br>
> > socketAddressBytes := ByteArray streamContents: [:strm | strm nextPutAll:<br>
> > socketAddress]. "==> #[245 55 26 98 28 0 0 0 10 0 0 0 0 0 0 0 38 7 248 176<br>
> > 64 9 8 9 0 0 0 0 0 0 32 14 0 0 0 0] "<br>
> > rs := socketAddressBytes readStream.<br>
> > networkSessionID := rs next: 8. "==> #[245 55 26 98 28 0 0 0] "<br>
> > addressSize := rs next: 8. "==> #[10 0 0 0 0 0 0 0] "<br>
> > rawAddressBytes := rs next: 16. "==> #[38 7 248 176 64 9 8 9 0 0 0 0 0 0<br>
> > 32 14] "<br>
> > padding := rs next: 4. "==> #[0 0 0 0] "<br>
> > rs atEnd. "==> true"<br>
> > NetNameResolver stringFromIPv6Address: rawAddressBytes. "==><br>
> > '2607:f8b0:4009:809::200e' "<br>
> ><br>
> ><br>
> > Dave<br>
> ><br>
> ><br>
> ><br>
> <br>
> -- <br>
> Eric<br>
<br>
> <br>
<br>
<br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div>Eric</div></div></div>