[BUG] Sockets aren't playing nice with me

Robert Withers withers at vnet.net
Fri Mar 3 03:45:10 UTC 2000


Lex Spoon wrote:
> 

Thanks for the response Lex.  I did manage to get it working at the
office today, which is good.  I am still unable to resolve offline.

> Well you posted a lot.  To answer a few questions:
> 
>         1. If you can't telnet to port 7, then ping isn't going to work.
> Probably a lot of people leave this service disabled nowadays, because
> the Internet isn't as friendly as it used to be.

Ok, I checked this out further and you are right.  The Linux ping uses
ICMP, whereas the Squeak uses TCP.

>         2. The waitFor *primitives* make sense because otherwise, the VM needs
> to deal with threads.  As is, another Squeak process can run while one
> process is waiting on a networking command to proceed.  Granted, it
> would be nice to have image-level support that didn't require the wait.

Ok, I see what you are saying.  I'll be patient. It can't be that far
down the road for multiple vm thread support.

>         3. The error returned from ping: is misleading, but that's probably
> because ping: simply can't tell whether it got a connection refused or a
> time out.  Networking failures are one place where it would be so nice
> if primitives could say *why* they failed.  Tim Rowledge once described
> a system similar to errno in Unix.  Sounds good to me.

Since I am up at work, I will continue with what I have and help revisit
this when the timing is better (threads)

cheers,
Rob
 
> Lex
> 
> Robert Withers <withers at vnet.net> wrote:
> > There have been several threads on the sockets in squeak over the past
> > several months which I have reviewed but I am still confused.  I
> > inspect:
> >
> > NetNameResolver localHostAddress.
> >
> > and I get 127.0.0.1  cool.  My clientServerTestUDP works, it seems to be
> > the TCP stuff.  Also my Socket ping: 'localhost' fails.  It seems that
> > connectTo:timeout: doesn't connect (through various tests) but this
> > issue doesn't show up until the waitForConnect stuff is called.  All of
> > my functionality works outside of squeak (Linux SuSU 6.3 on an intel).
> > Why isn't squeak working like the other network programs?  Why do we
> > have waitFor... methods?  Wouldn't it be better to have atomic socket
> > operations? (accept, listen, bind, connect, send, receive, disconnect,
> > destroy, setIOCtls, getIOCtls)   What can we do to fix this?  Do we need
> > FFI/Callin or can we continue to use named primatives?  It would be nice
> > to have a debug facility that we can turn on inside the primative code;
> > perhaps assertions?
> >
> > I wish I had more answers to post at this time, but I don't.  I would be
> > very interested in helping code a solution with design assistance.
> >
> > thanks,
> > Rob
> >
> > --
> > --------------------------------------------------
> > Smalltalking by choice.  Isn't it nice to have one!

-- 
--------------------------------------------------
Smalltalking by choice.  Isn't it nice to have one!





More information about the Squeak-dev mailing list