-----Mensaje original-----
De: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr]En nombre de Schwab,Wilhelm K
Enviado el: S�bado, 01 de Agosto de 2009 03:13 p.m.
Para: Pharo-project@lists.gforge.inria.fr
Asunto: Re: [Pharo-project] #remoteHostAddressCarlos,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: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Carlos Crosetti
Sent: Saturday, August 01, 2009 12:40 PM
To: Pharo-project@lists.gforge.inria.fr
Subject: Re: [Pharo-project] #remoteHostAddressI 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-----Mensaje original-----
De: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr]En nombre de Schwab,Wilhelm K
Enviado el: S�bado, 01 de Agosto de 2009 02:13 p.m.
Para: Pharo-project@lists.gforge.inria.fr
Asunto: Re: [Pharo-project] #remoteHostAddressFor '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.
Yes, wouldn't you expect 127.0.0.1 as the response from:
From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Ramiro Diaz Trepat
Sent: Saturday, August 01, 2009 9:00 AM
To: Pharo-project@lists.gforge.inria.fr; johnmci@smalltalkconsulting.com
Subject: Re: [Pharo-project] #remoteHostAddress
NetNameResolver addressForName: 'localhost'
?
On Fri, Jul 31, 2009 at 3:52 AM, John M McIntosh <johnmci@smalltalkconsulting.com> wrote:
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 <ramiro@diaztrepat.name
> > 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
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
--
=
=
=
========================================================================
John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter:
squeaker68882
Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
=
=
=
========================================================================
_______________________________________________
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project