[squeak-dev] The Inbox: Network-ul.100.mcz

Eliot Miranda eliot.miranda at gmail.com
Thu Jun 7 19:35:47 UTC 2012


On Thu, Jun 7, 2012 at 11:32 AM, Bert Freudenberg <bert at freudenbergs.de>wrote:

> On 06.06.2012, at 02:41, David T. Lewis wrote:
>
> > On Tue, Jun 05, 2012 at 05:11:53PM +0200, Bert Freudenberg wrote:
> >>
> >> On 05.06.2012, at 16:44, David T. Lewis wrote:
> >>
> >>> On Tue, Jun 05, 2012 at 03:13:20PM +0200, Bert Freudenberg wrote:
> >>>>
> >>>> On 05.06.2012, at 04:31, David T. Lewis wrote:
> >>>>
> >>>>> On Wed, Jun 22, 2011 at 08:29:29PM -0500, Chris Muller wrote:
> >>>>>> Just an FYI, the Magma test suite is pretty heavy on networking
> >>>>>> activity, but I didn't encounter any problems with this loaded.
> >>>>>>
> >>>>>> So what needs to happen for us as a community to make a decision on
> >>>>>> whether to accept or reject this?  I assume we will accept it, but
> >>>>>> maybe some of those more familiar with it can make some comments..?
> >>>>>> Who is our best networking expert who might want to review it and
> >>>>>> discuss?
> >>>>>
> >>>>> I have merged Levente's Network-ul.100 updates into the current
> Squeak
> >>>>> trunk, and made some additional changes to get unit tests working.
> >>>>>
> >>>>> The updates are in the inbox in Network-dtl.123 and
> NetworkTests-dtl.28.
> >>>>> I would appreciate if a couple of folks could load these updates,
> >>>>> run the network tests, and let us know if any problems arise.
> >>>>>
> >>>>> If there are no objections after a few days, I'll move the updates
> >>>>> to trunk and we can sort out any remaining issues there.
> >>>>>
> >>>>> Dave
> >>>>
> >>>> I committed a small fix to inbox as Network-bf.124. This is needed if
> you run on a VM that has only the old primitives (like, the Cog VM I'm
> using).
> >>>>
> >>>> With that fix the fallback code appears to work fine (at least I can
> use Monticello).
> >>>>
> >>>> A similar fix might be needed for Etoys, but we never ran into it,
> because we had the new plugin for ages.
> >>>>
> >>>> Btw, shouldn't asSocketAddress rather be an extension of the Network
> package?
> >>>>
> >>>
> >>> D'oh! Yes, asSocketAddress should be a Network package extension.
> Sorry.
> >>>
> >>> Dave
> >>
> >>
> >> After loading your tests package I get these failures (again, old
> SocketPlugin):
> >>
> >> HttpUrlTest>>#testHttps
> >> SocketTest>>#testLocalAddress
> >> SocketTest>>#testRemoteAddress
> >> SocketTestOldNetwork>>#testLocalAddress
> >> SocketTestOldNetwork>>#testRemoteAddress
> >>
> >> - Bert -
> >
> > I get different results on Linux, see attached.
> >
> > I suspect we will need some way to set UseOldNetwork at image startup
> time
> > in order to accomodate VMs that do not have the new network primitives.
> >
> > I believe that the testSendTimeout and testSocketReuse failures that I
> > am seeing are Linux specific, and not related to the new network changes
> > we are discussing here.
> >
> > I don't understand where the testHttps, testLocalAddress, and
> testRemoteAddress
> > failures are coming from. Can you double check and see if these failures
> > existed on your platform prior to the updates we are discussing? In other
> > words, are they Mac related, or are they caused by the network updates in
> > the inbox?
> >
> > Thanks!
> > Dave
>
>
>
> The testHttps failure was something local to my image. The other two fail
> in the same way, wether or not the new code is loaded:
>
> On Mac OS using the current Network code and a Cog VM (not your new
> package):
> 137 run, 135 passes, 0 expected failures, 2 failures, 0 errors, 0
> unexpected passes
> SocketTest>>#testLocalAddress
> SocketTest>>#testRemoteAddress
>
> Same VM and the new Network code today:
> 142 run, 140 passes, 0 expected failures, 2 failures, 0 errors, 0
> unexpected passes
> SocketTest>>#testLocalAddress
> SocketTest>>#testRemoteAddress
>
>
> testLocalAddress:
>        listenerSocket localAddress ==> #[0 0 0 0]
>        clientSocket localAddress ==> #[127 0 0 1]
>        serverSocket localAddress ==> #[127 0 0 1]
>        self listenerAddress ==> #[0 0 0 0]
>
> testRemoteAddress:
>        listenerSocket remoteAddress ==> #[0 0 0 0]
>        clientSocket remoteAddress ==> #[127 0 0 1]
>        serverSocket remoteAddress ==> #[127 0 0 1]
>        self listenerAddress ==> #[0 0 0 0]
>

I fixed the localAddress failures on MacOS X.  I'm committing now.  One
needs to change
platforms/unix/plugins/SocketPlugin/sqUnixSocket.c::sqResolverLocalAddress
to read, e.g.

sqInt sqResolverLocalAddress(void)
{   sqInt localaddr = nameToAddr(localHostName);
    if (!localaddr)
        localaddr = nameToAddr("localhost");
    return localaddr;
}

I'm pretty sure this occurs when one has a hostname set (e.g. my machine
McStalker) on a laptop and you change the network configuration (e.g. drop
a VPN connexion) that invalidates the hostname's ip.  Then nameToAddr
returns 0 and one needs to fallback on localhost/127.0.0.1.



> - Bert -
>
>
>
>


-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20120607/12f71899/attachment.htm


More information about the Squeak-dev mailing list