Re: [mico-devel] some wrong in using nameservie

2006-11-02 Thread Sorin Mustaca 


Hi gezi liu

>  Thanks for your help,I am so happy to tell you I have run it well
> this morning.After I correct the hosts once more ,it do well ,So ,i
> think, the reason is just the hosts.
This is usually the problem :)

>  I still type the telnet after run nsd and server,the result
> is:59.65.225.73:900/telnet: Name or service not known
> 59.65.225.73 :900 is the server ipaddress and port,Now i want to know
> what this result stand for?
So, I hope you typed:

telnet 59.65.225.73 900

If telnet can not connect there even if your server listens on that IP
and Port, means that also your client will not be able to connect.
So, you have some routing problem or a firewall running.
Or maybe the networking on the client is not well configured.
Conclusion: it is not a MICO problem, it has to do with your configuration.

>Thank you very much.
> liujinge
> 
> 
> 雅虎免费邮箱-3.5G容量，20M附件 
> 
> 
> 
> 
> ___
> Mico-devel mailing list
> Mico-devel@mico.org
> http://www.mico.org/mailman/listinfo/mico-devel

-- 
Regards,

Sorin Mustaca
Website: http://www.mustaca.de
Blog:http://www.mustaca.de/blog

___
Mico-devel mailing list
Mico-devel@mico.org
http://www.mico.org/mailman/listinfo/mico-devel

[mico-devel] some wrong in using nameservie

2006-11-02 Thread gezi liu 
Hi sorin Mustac: Thanks for your help,I am so happy to tell you I have run it well this morning.After I correct the hosts once more ,it do well ,So ,i think, the reason is just the hosts. I still type the telnet after run nsd and server,the result is:59.65.225.73:900/telnet: Name or service not known59.65.225.73 :900 is the server ipaddress and port,Now i want to know what this result stand for?    Thank you very much.    liujinge 
		 
雅虎免费邮箱-3.5G容量，20M附件___
Mico-devel mailing list
Mico-devel@mico.org
http://www.mico.org/mailman/listinfo/mico-devel

Re: [mico-devel] some wrong in using nameservice

2006-11-02 Thread Sorin Mustaca 
Hi,
Could you, please, perform the following tests:
1. start the Naming Service daemon and then the server
and then type "telnet   
Check if something happens.

2. Compile without SSL & CSIv2 and check if it works.

Let us know the results.


gezi liu wrote:
> Hi all:
>I will use nameservice with mico2.3.12 in Fedora 5,and now i am
> compiling the demo in 2.3.12,when the server and the client are in the
> same computer ,it run well ,but when they are in seperate computer,it
> has some wrong .
>  I have put the server's ipaddress and appropriate name in the hosts
> of both computer,and i also shut down the firewall of them.When i use
> nsadmin in client ,it also have a right result.
> But when i use the -ORBDbug All line to run the client,there are
> some failures ,the result are:
> 
> Using 0 as a concurrency model of whole orb.
> Using thread-pool concurrency model.
> Using client concurrency model: threaded
> MICO::InputHandler::InputHandler()
> ActiveMsgQueue::ActiveMsgQueue(): (0x8afbdc8)
> MICO::MTDispatcher::MTDispatcher()
> ActiveMsgQueue::ActiveMsgQueue(): (0x8afbfa8)
> CSIv2: added client user name: `' passwd: `'
> encoded realm name:
> 04 01 00 08 06 06 67 81   02 01 01 01 00 00 00 0e ..g.  
> 40 64 65 66 61 75 6c 74   5f 72 65 61 6c 6d   @default  _realm
> CSIv2::ComponentDecoder::ComponentDecoder()
> SecurityManager uses GIOP version 1.0
> IIOP: server listening on inet:0.0.0.0:45651 IIOP version 1.0
> binding to inet:59.65.225.72:45651
> void_array::__fast_insert (0x8afcc00):return 0
> ORB::add_invoke (MsgId=2)
> IIOP: making new GIOP 1.0 connection to inet:localhost:12345
> IIOP: connect to inet:localhost:12345 failed: Connection refused
> ORB::wait for 0x8afd5c0
> ORB::del_invoke (MsgId=2)
> Warning: cannot bind to Implementation Repository at inet:localhost:12345.
> Warning: will use a local Implementation Repository
> ORB::add_invoke (MsgId=3)
> IIOP: making new GIOP 1.0 connection to inet:server:12456
> GIOPCodec::GIOPCodec(): 0x8afaa18
> MICO::GIOPConnReader::GIOPConnReader(0x8afab18)
> GIOP: Codeset negotiation with inet:59.65.225.72:12456 using GIOP
> version 1.0
> GIOP: sending Request to inet:59.65.225.72:12456 msgid is 3
> IIOPProxy::add_invoke: rec=0x8afa428, id=0x8af9fa8, msgid=3)
> MICO::GIOPConn::output (CORBA::Buffer *b)
>  b: 0x8afa6a8
>   Out Data  47 49 4f 50 01 00 01 00 58 00 00 00 00 00 00 00 
> GIOPX...
> 03 00 00 00 01 00 00 00 0b 00 00 00 4e 61 6d 65 
> Name
> 53 65 72 76 69 63 65 00 06 00 00 00 5f 69 73 5f 
> Service._is_
> 61 00 00 00 00 00 00 00 28 00 00 00 49 44 4c 3a 
> a...(...IDL:
> 6f 6d 67 2e 6f 72 67 2f 43 6f 73 4e 61 6d 69 6e 
> omg.org/CosNamin
> 67 2f 4e 61 6d 69 6e 67 43 6f 6e 74 65 78 74 3a 
> g/NamingContext:
> 31 2e 30 00  1.0.
> ORB::wait for 0x8af9fa8
> MICO::GIOPConnReader::_run()
> MICO::GIOPConn::input_ready ()
>   conn: 0x8afab18
> ev: GIOPConnCallback::InputReady
>  t_mod: 0
>   pool: 
>   conn:
>req:
> _activerefs: 2
>In Data  47 49 4f 50 01 00 01 01 0d 00 00 00 00 00 00 00 
> GIOP
> 03 00 00 00 00 00 00 00 01   .
> IIOP: incoming data from inet:59.65.225.72:12456
> GIOP: incoming Reply from inet:59.65.225.72:12456 for msgid 3 status is 0
> ORB::get_invoke (MsgId=3)
> IIOPProxy::pull_invoke: id=0x8af9fa8, rec = 0x8afa428
> IIOPProxy::handle_invoke_reply: rec=0x8afa428)
> IIOPProxy::del_invoke: rec = 0x8afa428
> MICO::IIOPProxy::exec_invoke_reply (obj=0, *req=0x8afcda0, *conn=0x8afab18)
> ORB::del_invoke (MsgId=3)
> Looking up Bank ... ORB::add_invoke (MsgId=4)
> GIOP: sending Request to inet:59.65.225.72:12456 msgid is 4
> IIOPProxy::add_invoke: rec=0x8afa428, id=0x8af9e20, msgid=4)
> MICO::GIOPConn::output (CORBA::Buffer *b)
>  b: 0x8b02f60
>   Out Data  47 49 4f 50 01 00 01 00 41 00 00 00 00 00 00 00 
> GIOPA...
> 04 00 00 00 01 00 00 00 0b 00 00 00 4e 61 6d 65 
> Name
> 53 65 72 76 69 63 65 00 08 00 00 00 72 65 73 6f 
> Service.reso
> 6c 76 65 00 00 00 00 00 01 00 00 00 05 00 00 00 
> lve.
> 42 61 6e 6b 00 00 00 00 01 00 00 00 00   Bank.
> ORB::wait for 0x8af9e20
> GIOPConn::deref: 0x8afab18, refcnt: 2, activerefs: 2
> MICO::GIOPConn::input_ready ()
>   conn: 0x8afab18
> ev: GIOPConnCallback::InputReady
>  t_mod: 0
>   pool: 
>   conn:
>req:
> _activerefs: 2
>In Data  47 49 4f 50 01 00 01 01 90 00 00 00 00 00 00 00 
> GIOP�...
> 04 00 00 00 00 00 00 00 0d 00 00 00 49 44 4c 3a 
> IDL:
> 42 61 6e 6b 3a 31 2e 30 00 00 00 00 02 00 00 00 
> Bank:1.0
> 00 00 00 00 37 00 00 00 01 01 00 00 16 00 00 00 
> 7...
> 6c 6f 63 61 6c 68 6f 73 74 2e 6c 6f 63 61 6c 64 
> localhost.locald
> 6f 6d 61 6

[mico-devel] some wrong in using nameservice

2006-11-02 Thread gezi liu 
Hi all:   I will use nameservice with mico2.3.12 in Fedora 5,and now i am compiling the demo in 2.3.12,when the server and the client are in the same computer ,it run well ,but when they are in seperate computer,it has some wrong . I have put the server's ipaddress and appropriate name in the hosts of both computer,and i also shut down the firewall of them.When i use nsadmin in client ,it also have a right result.    But when i use the -ORBDbug All line to run the client,there are some failures ,the result are:Using 0 as a concurrency model of whole orb.Using thread-pool concurrency model.Using client concurrency model: threadedMICO::InputHandler::InputHandler()ActiveMsgQueue::ActiveMsgQueue(): (0x8afbdc8)MICO::MTDispatcher::MTDispatcher()ActiveMsgQueue::ActiveMsgQueue(): (0x8afbfa8)CSIv2: added client user name: `' passwd: `'encoded realm name:04
 01 00 08 06 06 67 81   02 01 01 01 00 00 00 0e ..g.  40 64 65 66 61 75 6c 74   5f 72 65 61 6c 6d   @default  _realmCSIv2::ComponentDecoder::ComponentDecoder()SecurityManager uses GIOP version 1.0IIOP: server listening on inet:0.0.0.0:45651 IIOP version 1.0binding to inet:59.65.225.72:45651void_array::__fast_insert (0x8afcc00):    return 0ORB::add_invoke (MsgId=2)IIOP: making new GIOP 1.0 connection to inet:localhost:12345IIOP: connect to inet:localhost:12345 failed: Connection refusedORB::wait for 0x8afd5c0ORB::del_invoke (MsgId=2)Warning: cannot bind to Implementation Repository at inet:localhost:12345.Warning: will use a local Implementation RepositoryORB::add_invoke (MsgId=3)IIOP: making new GIOP 1.0 connection to inet:server:12456GIOPCodec::GIOPCodec():
 0x8afaa18MICO::GIOPConnReader::GIOPConnReader(0x8afab18)GIOP: Codeset negotiation with inet:59.65.225.72:12456 using GIOP version 1.0GIOP: sending Request to inet:59.65.225.72:12456 msgid is 3IIOPProxy::add_invoke: rec=0x8afa428, id=0x8af9fa8, msgid=3)MICO::GIOPConn::output (CORBA::Buffer *b) b: 0x8afa6a8  Out Data  47 49 4f 50 01 00 01 00 58 00 00 00 00 00 00 00  GIOPX...    03 00 00 00 01 00 00 00 0b 00 00 00 4e 61 6d 65  Name    53 65 72 76 69 63 65 00 06 00 00 00 5f 69 73 5f  Service._is_    61 00 00 00 00 00 00 00 28 00 00 00 49 44 4c 3a  a...(...IDL:    6f 6d 67 2e 6f 72 67 2f 43 6f 73 4e 61 6d
 69 6e  omg.org/CosNamin    67 2f 4e 61 6d 69 6e 67 43 6f 6e 74 65 78 74 3a  g/NamingContext:    31 2e 30 00  1.0.ORB::wait for 0x8af9fa8MICO::GIOPConnReader::_run()MICO::GIOPConn::input_ready ()  conn: 0x8afab18    ev: GIOPConnCallback::InputReady t_mod: 0  pool:   conn:   req:_activerefs: 2   In Data  47 49 4f 50 01 00 01 01 0d 00 00 00 00 00 00 00  GIOP    03 00 00 00 00 00 00 00
 01   .IIOP: incoming data from inet:59.65.225.72:12456GIOP: incoming Reply from inet:59.65.225.72:12456 for msgid 3 status is 0ORB::get_invoke (MsgId=3)IIOPProxy::pull_invoke: id=0x8af9fa8, rec = 0x8afa428IIOPProxy::handle_invoke_reply: rec=0x8afa428)IIOPProxy::del_invoke: rec = 0x8afa428MICO::IIOPProxy::exec_invoke_reply (obj=0, *req=0x8afcda0, *conn=0x8afab18)ORB::del_invoke (MsgId=3)Looking up Bank ... ORB::add_invoke (MsgId=4)GIOP: sending Request to inet:59.65.225.72:12456 msgid is 4IIOPProxy::add_invoke: rec=0x8afa428, id=0x8af9e20, msgid=4)MICO::GIOPConn::output (CORBA::Buffer *b) b: 0x8b02f60  Out Data  47 49 4f 50 01 00 01 00 41 00 00 00 00 00 00 00  GIOPA...   
 04 00 00 00 01 00 00 00 0b 00 00 00 4e 61 6d 65  Name    53 65 72 76 69 63 65 00 08 00 00 00 72 65 73 6f  Service.reso    6c 76 65 00 00 00 00 00 01 00 00 00 05 00 00 00  lve.    42 61 6e 6b 00 00 00 00 01 00 00 00 00   Bank.ORB::wait for 0x8af9e20GIOPConn::deref: 0x8afab18, refcnt: 2, activerefs: 2MICO::GIOPConn::input_ready ()  conn: 0x8afab18    ev: GIOPConnCallback::InputReady t_mod: 0  pool:   conn:   req:_activerefs: 2   In Data  47 49 4f 50 01 00 01 01 90 00 00 00 00 00 00 00 
 GIOP�...    04 00 00 00 00 00 00 00 0d 00 00 00 49 44 4c 3a  IDL:    42 61 6e 6b 3a 31 2e 30 00 00 00 00 02 00 00 00  Bank:1.0    00 00 00 00 37 00 00 00 01 01 00 00 16 00 00 00  7...    6c 6f 63 61 6c 68 6f 73 74 2e 6c 6f 63 61 6c 64  localhost.locald    6f 6d 61 69 6e 00 43 ea 13 00 00 00 2f 35 36 37  omain.C�/567    31 2f 31 31 36 32 35 32 35 33 35 33 2f 5f 30 00  1/1162525353/_0.    01 00 00 00 24 00 00 00 01 00 00 00 01 00 00
 00  $...    01 00 00 00 14 00 00 00 01 00 00 00 01 00 01 00      00 00 00 00 09 01 01 00 00 00 00 00  IIOP: incoming data from inet:59.65.225.72:12456GIOP: incoming Reply from inet:59.65.225.72:12456 for msgid 4 status is 0ORB::get_invoke (MsgId=4)IIOPProxy::pull_invoke: id=0x8af9e20, rec = 0x8afa428IIOPProx