Re: connect two different machine

On 21-1-2015 16:26, Luca Delucchi wrote:
> On 21 January 2015 at 11:30, Luca Delucchi <[email protected]> wrote:
>> Hi everybody,
>>
>> I'm new user of Pyro, I read documentation and tutorial, I create a
>> test for my library and it work perfectly on localhost.
>> Now I'm trying to connect two different machine, I launched my script
>> on the server and it works correctly
>>
>> python grass_stem.py
>> Object <__main__.stemGRASS instance at 0x7f3402fb8b48>:
>>     uri = PYRO:obj_b2c0d990fa2241a0b30a9de0329a8519-prDWUKxKqPgbxR3XD4mAzA@public.gmane.org:39559
>>     name = stem.grass
>> Pyro daemon running.
>>
>>
>> python -m Pyro4.nsc --host=10.0.100.251 list

You shouldn't have to specify the host, Pyro should be able to locate the name server
automatically using the broadcast lookup mechanism (if your network configuration allows
it).

>> --------START LIST
>> Pyro.NameServer --> PYRO:[email protected]:9090
>> stem.grass --> PYRO:obj_b2c0d990fa2241a0b30a9de0329a8519-prDWUKxKqPgbxR3XD4mAzA@public.gmane.org:39559
>> --------END LIST

>> When I try to work from my client I obtain these errors
>>
>> python -m Pyro4.nsc --host=10.0.100.251 list
>> Failed to locate the name server: Failed to locate the nameserver

Your client machine can't reach the Pyro (name) server running on the specified host,
simple as that. Why that is, is hard to say, because it's almost certainly a
configuration issue on your end. The regular checklist applies:


- can you ping the server from your client machine
- can you telnet to the given host+port from your client machine
- is the server's ip address as shown one of an externally reachable network interface
- do you have a firewall or packetfilter running that prevents the connection
- do you have the same Pyro versions on both server and client
- what does the pyro logfiles tell you (enable it via the config items on both the
server and the client, including the name server. See
http://pythonhosted.org/Pyro4/tipstricks.html#logging)
- (if not using the default:) do you have a compatible serializer configuration
- (if not using the default:) do you have a symmetric hmac key configuration
- can you obtain a few bytes from the wire using netcat, see
http://pythonhosted.org/Pyro4/tipstricks.html#wire-protocol-version


Might just as well add this to the troubleshooting chapter in the manual come to think
of it....

>>
>> import Pyro4
>> import os
>> gs = Pyro4.Proxy("PYRONAME:[email protected]:39559")

That ain't right: the 39559 port is not the name server's port; it's the port of your
actual pyro server. You're probably confusing PYRO: and PYRONAME: uri's here.

Either use the object's uri as printed from your stem.py code (and as listed in the name
server):
	"PYRO:obj_b2c0d990fa2241a0b30a9de0329a8519-prDWUKxKqPgbxR3XD4mAzA@public.gmane.org:39559"
or use the logical name you registered this with in the name server:
	"PYRONAME:stem.grass"
	(in which case Pyro will be doing a lookup in the name server for you)
	(and you're not required to add the name server's hostname and port here)


> more information: running the server with strace, when I try to query
> the server from the client I obtain this
> 
> {sa_family=AF_INET, sin_port=htons(33239),
> sin_addr=inet_addr("10.0.101.18")}, [16]) = 7
> futex(0x7f673c001650, FUTEX_WAKE_PRIVATE, 1) = 1
> futex(0x16d1bd0, FUTEX_WAKE_PRIVATE, 1) = 1
> futex(0x16d1bd0, FUTEX_WAIT_PRIVATE, 0, NULL) = -1 EAGAIN (Resource
> temporarily unavailable)
> futex(0x1825fe0, FUTEX_WAKE_PRIVATE, 1) = 1
> futex(0x16d1bd0, FUTEX_WAKE_PRIVATE, 1) = 1
> 
> at least the client and the server are in touch :-)

That is too low level for me, I can't make much sense of this sorry.
In any case it is not normally needed to descend to this low level to fix your
(pyro)connection issue. Try the checklist I talked about earlier first.


Irmen


------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet