#remoteHostAddress
Locked
 
|
I am trying to port Magma to Pharo, and I have run across the following issue.
Ini Pharo, the method: Socket>>connectTo: hostAddress port: port waitForConnectionFor: timeout
(mir 6/17/2007 20:10) "Initiate a connection to the given port at the given host address. Waits until the connection is established or time outs."
self connectNonBlockingTo: hostAddress port: port. self waitForConnectionFor: timeout
ifTimedOut: [ConnectionTimedOut signal: 'Cannot connect to ' , self remoteHostAddress hostNumber , ':' , port asString]
#remoteHostAddress has no implementors in Pharo. The implementation of this method in Squeak uses NetNameResolver
Socket>>connectTo: hostAddress port: port waitForConnectionFor: timeout (mu 8/14/2003 15:15) "Initiate a connection to the given port at the given host
address. Waits until the connection is established or time outs." self connectNonBlockingTo: hostAddress port: port.
self waitForConnectionFor: timeout ifTimedOut: [ConnectionTimedOut signal: 'Cannot connect to '
, (NetNameResolver stringFromAddress: hostAddress) , ':' , port asString] Who is maintaining Socket now in Pharo?
Has anyone got some advice on how to solve this? Cheers r. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
Sorry, this mail came out too quick. How to report the error is a secondary matter.
I believe the issue is about localhost name resolution. I think this was discussed around the Windows VM platform, but I am on a Mac.
NetNameResolver addressForName: 'localhost' does not return 127.0.0.1 And, NetNameResolver localHostAddress
returns the address on the network leg (192.168.....) instead of 127.0.0.1 Is the convention that localhost is always 127.0.0.1 ? Cheers
r. On Thu, Jul 30, 2009 at 9:20 PM, Ramiro Diaz Trepat <[hidden email]> wrote: I am trying to port Magma to Pharo, and I have run across the following issue. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
Well that does
^NetNameResolver addressForName: self localHostName where self localHostName on my machine returns 'Otter-2.local' where it really does addressesForName: and then if there is more than one then addresses first socketAddress So for my mac it's fe80::21c:42ff:fe00:9%en5(Otter-2), 0(0)-inet6-stream-tcp fe80::21c:42ff:fe00:8%en5(fe80::21c: 42ff:fe00:8%en5), 0(0)-inet6-stream-tcp fe80::21b:63ff:fe02:d2db%en5(fe80::21b: 63ff:fe02:d2db%en5), 0(0)-inet6-stream-tcp 10.37.129.2(10.37.129.2), 0(0)-inet4-stream-tcp 10.211.55.2(10.211.55.2), 0(0)-inet4-stream-tcp 192.168.1.139(192.168.1.139), 0(0)-inet4-stream-tcp where it has 4 ipv 6 address and 3 ipv 4 addresses. and doing NetNameResolver localHostAddress then gives: fe80::21c:42ff:fe00:9%en5(Otter-2),0(0) The problem then is figuring out what you want, versus grabbing the first element in the list of IP address serviced by the machine. Perhaps in this case you thought you should get 192.168.1.139? Now if I ask for ^NetNameResolver addressForName: 'localhost' then I get back ::1(localhost),0(0) On 30-Jul-09, at 2:07 PM, Ramiro Diaz Trepat wrote: > Sorry, this mail came out too quick. How to report the error is a > secondary matter. > I believe the issue is about localhost name resolution. I think > this was discussed around the Windows VM platform, but I am on a Mac. > > > NetNameResolver addressForName: 'localhost' > > does not return 127.0.0.1 > > And, > > NetNameResolver localHostAddress > > returns the address on the network leg (192.168.....) instead of > 127.0.0.1 > > Is the convention that localhost is always 127.0.0.1 ? > > > Cheers > > > r. > > > On Thu, Jul 30, 2009 at 9:20 PM, Ramiro Diaz Trepat <[hidden email] > > wrote: > I am trying to port Magma to Pharo, and I have run across the > following issue. > > Ini Pharo, the method: > > Socket>>connectTo: hostAddress port: port waitForConnectionFor: > timeout > (mir 6/17/2007 20:10) > > "Initiate a connection to the given port at the given host > address. Waits until the connection is established or time outs." > self connectNonBlockingTo: hostAddress port: port. > self > waitForConnectionFor: timeout > ifTimedOut: [ConnectionTimedOut signal: 'Cannot connect to ' > , self remoteHostAddress hostNumber , ':' , port asString] > > > #remoteHostAddress has no implementors in Pharo. > > The implementation of this method in Squeak uses NetNameResolver > > Socket>>connectTo: hostAddress port: port waitForConnectionFor: > timeout > (mu 8/14/2003 15:15) > "Initiate a connection to the given port at the given host > address. Waits until the connection is established or time outs." > self connectNonBlockingTo: hostAddress port: port. > self > waitForConnectionFor: timeout > ifTimedOut: [ConnectionTimedOut signal: 'Cannot connect to ' > , (NetNameResolver stringFromAddress: hostAddress) , ':' , port > asString] > > Who is maintaining Socket now in Pharo? > Has anyone got some advice on how to solve this? > Cheers > > r. > > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- = = = ======================================================================== John M. McIntosh <[hidden email]> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ======================================================================== _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
Yes, wouldn't you expect 127.0.0.1 as the response from:
NetNameResolver addressForName: 'localhost' ? On Fri, Jul 31, 2009 at 3:52 AM, John M McIntosh <[hidden email]> wrote: Well that does _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
For 'localhost', sure, 127.0.0.1 is probably the
correct response. However, one can also run into situations of needing to
find "the" current IP number/name. There are also servers with multiple
addresses, and numbers with multiple names.
From: [hidden email] [mailto:[hidden email]] On Behalf Of Ramiro Diaz Trepat Sent: Saturday, August 01, 2009 9:00 AM To: [hidden email]; [hidden email] Subject: Re: [Pharo-project] #remoteHostAddress NetNameResolver addressForName: 'localhost' ? On Fri, Jul 31, 2009 at 3:52 AM, John M McIntosh <[hidden email]>
wrote: Well that does _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
I
agree. localhost bound to the loop address is the ip atandard, and based on the
stack implementation you run on, you may wish to define localhost to resolve
different, you haev the configuration files to change that
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
Carlos,
What if one cannot (admin rights) or simply does
not wish to be bothered tweaking configurations? I found a goofy sequence
of operations that correctly resolved local names, at least on
Windows, and will eventually replicate that in Pharo.
Bill
From: [hidden email] [mailto:[hidden email]] On Behalf Of Carlos Crosetti Sent: Saturday, August 01, 2009 12:40 PM To: [hidden email] Subject: Re: [Pharo-project] #remoteHostAddress I
agree. localhost bound to the loop address is the ip atandard, and based on the
stack implementation you run on, you may wish to define localhost to resolve
different, you haev the configuration files to change that
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
Bill,
I dont see a problem if Pharo features some alternate mechanism that may change
the result of resolving localhost to another address. I would not insist,
localhost is something I associate to a reserved word - perhaps is too much
saying localhost comes from a standard
Carlos
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
Carlos,
No worries. I **agree** with you about
'localhost' - that should resolve to the standard value if at all
possible. When one gets "the" local IP number and asks for the name of
that, then the (first) fully qualified DNS entry would be the natural
choice.
My point is simply that it is easy to say "change your
network configuration," but what if one is lucky to get enough IT support to
make a DNS entry, let alone investigate subtle points of the network
configuration to make it work. I had huge problems with this, much of
which came from Windows itself, and probably some from other sources to remain
nameless.
There is weirdness here that goes beyond my
failure to send the (anachronistic IMHO) #initializeNetwork before doing the
lookup on a LINUX MACHINE. Another bug, I know, but it's easy to blame the
network; it's harder to fix it sometimes, especially when it's not at
fault.
Bill
From: [hidden email] [mailto:[hidden email]] On Behalf Of Carlos Crosetti Sent: Saturday, August 01, 2009 6:37 PM To: [hidden email] Subject: Re: [Pharo-project] #remoteHostAddress Bill,
I dont see a problem if Pharo features some alternate mechanism that may change
the result of resolving localhost to another address. I would not insist,
localhost is something I associate to a reserved word - perhaps is too much
saying localhost comes from a standard
Carlos
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |