[squeak-dev] The Trunk: Network-dtl.240.mcz

Levente Uzonyi leves at caesar.elte.hu
Thu Apr 23 15:36:12 UTC 2020


On Thu, 23 Apr 2020, Marcel Taeumel wrote:

> Looking at "Socket newTCP", IPv6 is not even considered. One has to call "Socket newTCP: SocketAddressInformation addressFamilyINET6". Maybe out IPv6 preferences needs to be considered more often?

Right, so #newTCP defines the family prematurely. In my opinion, it should 
happen when the interface (which is actually an address not an interface) 
is specified because the two address families can contradict, as the 
example showed.

Let's do it the "right" way:

s := Socket newTCP: SocketAddressInformation addressFamilyINET6.
s listenOn: 60000 backlogSize: 8 interface: (NetNameResolver addressForName: '::1').
s "==>  a Socket[destroyed]".

Still destroyed. Why?
Perhaps because #listenOn:backlogSize:interface: tries to convert the 
address with #asByteArray and (NetNameResolver addressForName: '::1') 
asByteArray returns #[1] (what?).
So, let's remove that #asByteArray send hoping that the VM can handle the 
new opaque addresses.

s := Socket newTCP: SocketAddressInformation addressFamilyINET6.
s listenOn: 60000 backlogSize: 8 interface: (NetNameResolver 
addressForName: '::1').
s "==>  a Socket[destroyed]".

Still destroyed, so that didn't help. Why?
Let's have a look at the plugin code (unix this time)[1]:

void sqSocketListenOnPortBacklogSizeInterface(SocketPtr s, sqInt port, sqInt backlogSize, sqInt addr)

Okay, addr must be a pointer to one of those opaque blobs.

saddr.sin_port= htons((short)port);

That short was meant to be unsigned short, right?

saddr.sin_addr.s_addr= htonl(addr);

The VM code expects addr to be a 4-byte unsigned integer (where's the 
cast?) representing an IPv4 address in host byte order.
So, too bad, #listenOn:backlogSize:interface: 
(primitiveSocketListenOnPortBacklogInterface) does not support IPv6. It 
never did.


Levente

[1] https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/platforms/unix/plugins/SocketPlugin/sqUnixSocket.c#L708

> Best,
> Marcel
>
>       Am 23.04.2020 16:57:44 schrieb Levente Uzonyi <leves at caesar.elte.hu>:
>
>       On Thu, 23 Apr 2020, Marcel Taeumel wrote:
>
>       > Hi all!
>       > I am on Windows 10. This is my output for the usual calls. Maybe it helps:
>       >
>       > SocketAddressInformation
>       > forHost: 'localhost'
>       > service: '12345'
>       > flags: 0
>       > addressFamily: 0
>       > socketType: SocketAddressInformation socketTypeStream
>       > protocol: SocketAddressInformation protocolTCP.
>       >
>       > " an OrderedCollection(::1(MOBILUS-TAB-NEW),12345(12345)-inet6-stream-tcp 127.0.0.1(MOBILUS-TAB-NEW),12345(12345)-inet4-stream-tcp)"
>       >
>       > NetNameResolver addressForName: 'localhost'.
>       >
>       > " ::1(MOBILUS-TAB-NEW),0(0)"
>       >
>       > ***
>       >
>       > Socket >> #connectTo: times out. Basically "WebClient httpGet: 'http://localhost:12345/test/auth'" does not work. ConnectionRefused.
>
>       I suspect that the server only listens on the IPv4 address while, due to
>       its undeterministic nature (it returns the first address no matter how
>       many are there, and the order of the addresses is not defined),
>       #addressForName: gives you the IPv6 address, so the client can't
>       connect to the server.
>
>       Another issue is that listening on IPv6 addresses is not possible (at
>       least on my machine):
>
>       IPv4 works:
>
>       s := Socket newTCP.
>       s listenOn: 60000 backlogSize: 8 interface: (NetNameResolver
>       addressForName: '127.0.0.1').
>       s "==> a Socket[waitingForConnection]"
>
>       IPv6 does not work. It just fails silently:
>
>       s := Socket newTCP.
>       s listenOn: 60000 backlogSize: 8 interface: (NetNameResolver
>       addressForName: '::1').
>       s "==> a Socket[destroyed]"
> 
>
>       Levente
>
>       >
>       > Best,
>       > Marcel
>       >
>       > Am 23.04.2020 09:42:00 schrieb John Pfersich via Squeak-dev :
>       >
>       > The network resolvers are definitely different in Linux and MacOS, the one in MacOS is less forgiving, or maybe it’s less robust.
>       >
>       > /—————————————————————/For encrypted mail use jgpfersich at protonmail.com - Free account at ProtonMail.comWeb: https://objectnets.net and https://objectnets.org
>       > https://datascilv.com https://datascilv.org
>       >
>       >
>       > On Apr 22, 2020, at 18:36, David T. Lewis wrote:
>       >
>       > I have to suspect platform differences at this point. I think that you
>       > are using OS X (is that right?) and I expect that the network resolver
>       > may behave quite differently on different platforms, so we'll need to
>       > collect a few more data points to see where the issues are.
>       >
>       >
>       >
> 
> 
>


More information about the Squeak-dev mailing list