[squeak-dev] The Inbox: Network-EG.246.mcz

David T. Lewis lewis at mail.msen.com
Tue Jul 27 23:42:22 UTC 2021


Hi Eric,

To be honest I'm not sure what we should do. Maybe nothing. Like you,
I am a reader of the code, not a writer. But after poking around with
it (thanks in good measure to your inbox submission), my sense of it
is that the design intent of the network resolver primitives was for
socket information to be opaque (not directly meaningful in the image,
and typically in practice being a byte copy of some data structure
in the VM plugins). We see similar things throughout the file and
and socket plugins.

I have personally abused the "opaque" fileID handle in our file streams
when I implemented OSProcess/CommandShell, and I remember being sternly
lectured by Andreas Raab on that topic. He was not wrong, and IMHO
neither was I, but I don't know the right balance here.

I think that Andreas and Ian Piumarta were working together on the
socket plugin and network resolver primitives, and I think that their
underlying philosophy was that security and reliability were important,
and therefore that handles on data structures in the VM (such as file
and socket information data structures) should be treated as meaningless
bags of bytes on the image side. VM plugins can handle this safely and
reliably, but the VM tends to get confused when people like you and me
mess around with the internals of the opaque data structure bytes.

In fact, I also remember Andreas proposing a scheme (never implemented)
to replace our current "bag of bytes" handles for socket and file data
structures with integer handles that were guaranteed to make the data
structure internals invisible to the image. I was not personally in
favor of that (because it would have made OSProcess infeasible) but
I do understand the motivation.

Dave


On Tue, Jul 27, 2021 at 06:40:40PM -0400, Eric Gade wrote:
> Hi Dave,
> 
> Thanks, those examples give me a better understanding of what's going on
> here. What do you think we should do? It seems that SocketAddress >>
> #asByteArray also assumes IPv4, so I could update that to use the new
> NetNameResolver methods too. But is there anything else? Should
> #stringFromIPv6Address: and #addressFromIPv6String be updated to respond
> with appropriately configured SocketAddress instances, rather than plain
> ByteArrays?
> 
> On Sun, Jul 25, 2021 at 6:36 PM David T. Lewis <lewis at mail.msen.com> wrote:
> 
> > On Tue, Jul 20, 2021 at 06:16:51PM +0000, commits at source.squeak.org wrote:
> > > A new version of Network was added to project The Inbox:
> > > http://source.squeak.org/inbox/Network-EG.246.mcz
> > >
> > > ==================== Summary ====================
> > >
> > > Name: Network-EG.246
> > > Author: EG
> > > Time: 20 July 2021, 2:16:51.031725 pm
> > > UUID: 286844ab-38ff-4f7d-97a4-37d69eda41e5
> > > Ancestors: Network-ct.245
> > >
> > > Adding methods and helpers for:
> > > 1. Converting from an IPv6 string to an IPv6 ByteArray;
> > > 2. Converting from an IPv6 ByteArray to a valid IPv6 string.
> > >
> > > Note that the complexity here is mostly taken up in dealing with the IPv6
> > > "feature" of compressing the longest consecutive series of 0 values to
> > > the string '::'.
> > >
> > > I have also updated the plain #addressFromString: and #stringFromAddress:
> > > methods to first try and see if they are dealing with what appears to
> > > be and IPv6 string/bytes and to call the IPv6 specialized versions of
> > > the method if so.
> > >
> >
> > Interesting work, thanks. Here are some workspace doIts that illustrate
> > how the raw address bytes related to the socket address information
> > that is managed in the SocketPlugin in the VM. I used 'google.com' as
> > an example, because the resolver on my computer gives both an IPv4 and
> > IPv6 address listing. I am on a 64-bit machine, and the socketAddressBytes
> > below would be different on a 32-bit machine.
> >
> > google := NetNameResolver addressesForName: 'google.com'.
> > googleIPV6 := google second. "==> 2607:f8b0:4009:809::200e(
> > ord37s33-in-x0e.1e100.net),0(0)-inet6-stream-tcp "
> > socketAddress := googleIPV6 socketAddress. "==> 2607:f8b0:4009:809::200e(
> > ord37s33-in-x0e.1e100.net),0(0) "
> > socketAddress size. "==> 36 "
> > socketAddressBytes := ByteArray streamContents: [:strm | strm nextPutAll:
> > socketAddress]. "==> #[245 55 26 98 28 0 0 0 10 0 0 0 0 0 0 0 38 7 248 176
> > 64 9 8 9 0 0 0 0 0 0 32 14 0 0 0 0] "
> > rs := socketAddressBytes readStream.
> > networkSessionID := rs next: 8. "==> #[245 55 26 98 28 0 0 0] "
> > addressSize := rs next: 8. "==> #[10 0 0 0 0 0 0 0] "
> > rawAddressBytes := rs next: 16. "==> #[38 7 248 176 64 9 8 9 0 0 0 0 0 0
> > 32 14] "
> > padding := rs next: 4. "==> #[0 0 0 0] "
> > rs atEnd. "==> true"
> > NetNameResolver stringFromIPv6Address: rawAddressBytes. "==>
> > '2607:f8b0:4009:809::200e' "
> >
> >
> > Dave
> >
> >
> >
> 
> -- 
> Eric

> 



More information about the Squeak-dev mailing list