[BUG] Sockets aren't playing nice with me
Lex Spoon
lex at cc.gatech.edu
Sun Mar 5 14:13:20 UTC 2000
Did you guys do a "Socket initializeNetwork" before doing those lookups?
These examples work fine for me on Linux, *if* I have done
initializeNetwork first. If not, then the first one returns nil.
Forgetting initializeNetwork seems to be very easy. I wonder if all
Socket primitives should just do this implicitly?! Heck, why even
export it to the Squeak level anyway?
Lex
John Clonts <jclonts at mastnet.net> wrote:
> Hmmm, this *is* sounding a bit like what I was dealing with several
> weeks ago. Are you saying that
>
> NetNameResolver addressForName: 'ibm.com' --> nil
> but
> NetNameResolver addressForName: '204.146.80.99' --> #(204 146 80 99)
>
> ???
>
> What version of libc is your linux using?
>
> (my problem had to do with the use of the glibc2 libraries, when I
> recompiled the from sources it uses the older libc and works fine...)
>
>
> Cheers,
> John
>
> Robert Withers wrote:
> >
> > Yes, I'm not holding my breathe on VM threads and we should need them as
> > you said. I am using the ObjectSocket which is a SocketStream. I
> > started having the problems again this morning. In bash, I can resolve
> > localhost -> 127.0.0.1, babylon -> 192.168.1.10, and ibm.com ->
> > 204.146.80.99. This exercises the hosts file (for the first two) and
> > DNS for the third. I have a default gateway (192.168.1.7) that traffic
> > is routing to to get to DNS which is out there somewhere.
> >
> > In the attachment I included two scripts, "Works" and "Broken". It is
> > the NetNameResolver which returns '0.0.0.0' for the 'localhost' name.
> > Other names ('ibm.com') return nil.
> >
> > Lex Spoon wrote:
> > >
> > > Robert Withers <withers at vnet.net> wrote:
> > > > 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.
> > > >
> > >
> > > I don't think VM threads are going to happen any time soon. What some
> > > people have done is made a sort of SocketStream which has regular
> > > blocking commands like #next and #next:. If you use these instead of
> > > using a Socket directly, then you don't have to explicitly do the waits.
> > >
> > > VM threads make things more complicated, and they don't seem to have a
> > > big advantage.
> > >
> > > > Since I am up at work, I will continue with what I have and help revisit
> > > > this when the timing is better (threads)
> > > >
> > >
> > > Is the lack of VM threads causing you any difficulty? I bet there is a
> > > way to make it work with the current scheme.
> > >
> > > Lex
> >
> > --
> > --------------------------------------------------
> > Smalltalking by choice. Isn't it nice to have one!
> >
> > ---------------------------------------------------------------
> > "Works"
> > |s|
> > Socket initializeNetwork.
> > s := Socket newTCP.
> > s connectTo: (NetNameResolver addressForName: '127.0.0.1') port: 21.
> > s waitForConnectionUntil: Socket standardDeadline.
> > s sendSomeData: (String cr, String cr).
> > 1 to: 10 do: [:i |
> > s sendSomeData: (String cr, String cr).
> > [s dataAvailable] whileTrue: [Transcript cr; show: s getData printString]].
> > s destroy.
> >
> > "Broken"
> > |s|
> > Socket initializeNetwork.
> > s := Socket newTCP.
> > s connectTo: (NetNameResolver addressForName: 'localhost') port: 21.
> > s waitForConnectionUntil: Socket standardDeadline.
> > s sendSomeData: (String cr, String cr).
> > 1 to: 10 do: [:i |
> > s sendSomeData: (String cr, String cr).
> > [s dataAvailable] whileTrue: [Transcript cr; show: s getData printString]].
> > s destroy.
More information about the Squeak-dev
mailing list
|