Home Help Center

ice_pings in callbacks when there is a reconnection

josemp10josemp10 Member Jose GarciaOrganization: Rey Juan Carlos UniversityProject: Programming distributed among vehicles
Hi all,

I have n computers connected by Ethernet in a local network. (n-1) computers are clients and 1 of them is with the server role. The clients send some text messages to the other clients through the server (is just a logical star topology and the server is the central node) using the Ice middle-ware. Both clients and servers are implemented in Java on a Ubuntu machine.

Each 5 seconds, the server send a ping signal to each client to know if "there is somebody there". To do that the server stores the client's proxies in a hash table:

String[] clientIds = clients.keySet().toArray(new String[clients.size()]);
for (String clientId : clientIds)
{
try{
clients.get(clientId).ice_ping();
}
catch (TimeoutException ex)
{
// Do something
}
}

Everything works fine, but when i simulate a loss of connection (just disconnecting the cable) logically the ping produces a TimeoutException (i do not nothing relevant for the proxies inside the catch block) and after, when i connect again, there is no possible down-connection between the server to the client (the ice_ping always throw a TimeoutException). In this case the communication is always working between the client to the server, but it isn't in the opposite.

Could you give some help about this?

Thank you very much!!

Comments

  • marcmarc FloridaAdministrators, ZeroC Staff Marc LaukienOrganization: ZeroC, Inc.Project: The Internet Communications Engine ZeroC Staff
    You should switch connection tracing on for both the clients and the server. Try to find the traces for the failed pings. This trace might already give you enough information about the problem, or if you still can't find the problem, post the relevant traces here.
  • josemp10josemp10 Member Jose GarciaOrganization: Rey Juan Carlos UniversityProject: Programming distributed among vehicles
    Thanks for your quick answer Marc and sorry for delaying the mine. Unfortunately i had an accident last week and for now i cannot make the test (i am in hospital now). I'll do as soon as possible (hope next week). Thanks.
  • josemp10josemp10 Member Jose GarciaOrganization: Rey Juan Carlos UniversityProject: Programming distributed among vehicles
    Well, finally at home again :).

    I switch to connection tracing on for both clients and server. When the connection is established, each 5 seconds the server send and receive the follow information (i think 77 bytes are from the ping signal and the client response with 25 bytes of ACK):

    [ 8/11/11 16:57:55:010 Network: sent 77 of 77 bytes via tcp
    local address = 193.147.53.2:38011
    remote address = 81.44.237.156:43397 ]
    [ 8/11/11 16:57:55:082 Network: received 14 of 14 bytes via tcp
    local address = 193.147.53.2:38011
    remote address = 81.44.237.156:43397 ]
    [ 8/11/11 16:57:55:082 Network: received 11 of 11 bytes via tcp
    local address = 193.147.53.2:38011
    remote address = 81.44.237.156:43397 ]



    And for the client (receives 77 bytes from server and send 25 bytes of ACK)

    [ 8/11/11 16:57:55:010 Network: sent 77 of 77 bytes via tcp
    local address = 193.147.53.2:38011
    remote address = 81.44.237.156:43397 ]
    [ 8/11/11 16:57:55:082 Network: received 14 of 14 bytes via tcp
    local address = 193.147.53.2:38011
    remote address = 81.44.237.156:43397 ]
    [ 8/11/11 16:57:55:082 Network: received 11 of 11 bytes via tcp
    local address = 193.147.53.2:38011
    remote address = 81.44.237.156:43397 ]


    when i disconnect the cable (i catch the TimeoutException of the server), the server sends the follow information (ping) and close the tcp connection:

    [ 8/11/11 16:58:05:156 Network: sent 77 of 77 bytes via tcp
    local address = 193.147.53.2:38011
    remote address = 81.44.237.156:43397 ]
    [ 8/11/11 16:58:07:157 Network: closing tcp connection
    local address = 193.147.53.2:38011
    remote address = 81.44.237.156:43397 ]

    Of course no ping arrives to client. But if a reconnect it, the client shows (receive the ping, send ACK and close the connection):


    [ 11/08/11 17:03:18:509 Network: received 14 of 14 bytes via tcp
    local address = 10.0.0.8:43397
    remote address = 193.147.53.2:38011 ]
    [ 11/08/11 17:03:18:509 Network: received 63 of 63 bytes via tcp
    local address = 10.0.0.8:43397
    remote address = 193.147.53.2:38011 ]
    [ 11/08/11 17:03:18:510 Network: sent 25 of 25 bytes via tcp
    local address = 10.0.0.8:43397
    remote address = 193.147.53.2:38011 ]
    [ 11/08/11 17:03:18:572 Network: closing tcp connection
    local address = 10.0.0.8:43397
    remote address = 193.147.53.2:38011 ]


    And that's all. Server's pings don't arrive to client anymore, but i think the Ice connection should be restored automatically, isn't it?

    mmm... i configure bidirectional connections manually (as is specified in the 36.7 of Ice manual). Could this be related with the problem?

    Thank you very much!
  • marcmarc FloridaAdministrators, ZeroC Staff Marc LaukienOrganization: ZeroC, Inc.Project: The Internet Communications Engine ZeroC Staff
    josemp10 wrote: »
    mmm... i configure bidirectional connections manually (as is specified in the 36.7 of Ice manual). Could this be related with the problem?

    Yes, if you manually establish connections, and use fixed proxies, then such proxies are tied to the connection you use them with. Ice cannot reestablish connections for such proxies, as the lifetime of the proxy is then tied to the lifetime of the connection.

    Have a look at Bidirectional Connections - Ice 3.4 - ZeroC for more information.
  • josemp10josemp10 Member Jose GarciaOrganization: Rey Juan Carlos UniversityProject: Programming distributed among vehicles
    Thanks again for your quick answer Marc.

    As at the moment we are working in a Local network without firewalls (and things like that) i will change the type of the proxies to connect clients with the server. Anyway, could Glacier2 be a solution for callbacks (in the case of different computers in different networks), when the communication may fail (in a physical level)? or do we have the same problem? (i' ve never worked before with Glacier2).

    Thanks!
  • marcmarc FloridaAdministrators, ZeroC Staff Marc LaukienOrganization: ZeroC, Inc.Project: The Internet Communications Engine ZeroC Staff
    Glacier2 is a firewall traversal solution and a session manager. Your client must be aware of Glacier2 and establish connections/sessions, and take care of handling connection loss. Servers do not need to be aware of Glacier2. For more information on Glacier2, check out our manual, or these articles.
Sign In or Register to comment.