Conflicts

From Wiki for iCub and Friends
Jump to: navigation, search

This page helps you debug the dreaded "address conflict problem".

Introduction

Address conflict has been a frequent problem in YARP. This problem happens when a port tries to open a socket that is already in use by another process/port. Traditionally in YARP this problem happened in these situations:

  • when one process does not terminate correctly (the name server thinks the process is dead but it is not and is still using the resources it had)
  • when you stop the name server and forget to restart all processes (the process runs, but in fact the nameserver does not know anything about it so it recycles the resources currently used by the process)
  • simliar to 2), if you manually unregister a port that is still active
  • a non-yarp process is using one of the port managed by the YARP nameserver

In all cases there is one process that holds a socket but the name server does not know it, so it re-assigns the same socket to another process. The second process complains saying that there is an "address conflict".

Please notice that the new name server yarpserver3 has better support for handling this problem. Address conflicts should not happen when using yarpserver3, see below.

Traditional name server: what to do

Suppose you get this error:

yarp: Port /myPortName failed to activate at tcp://10.0.0.19:10152 (address conflict)

The best solution is to use the following commands, replacing 10152 with the number given in the failure message:

lsof | grep 10152
lsof | grep yarp
lsof | grep <any-of-the-names-of-your-yarp-processes>
netstat -lpn | grep 10152
netstat -lpn

so as to to understand which process is using the given port. Once the process has been found just kill it.

If you want to clean unused ports, you can use the following command:

yarp clean

The command might get stuck while unregistering some specific ports (typically windows machine ports, if windows is accepting tcp connections to non-existing sockets but never responding to them). The solution is usually to unregister the port where the 'yarp clean' get stuck using the command 'yarp name unregister /stuckPort'.

New nameserver, yarpserver3

yarpserver3 tries to assign each distinct port name a distinct socket number, and keep that number constant for as long as the server's database is preserved. The socket number should not change from run to run, and should not depend on the identity of the machine the port exists on.

So, if conflicts occur, they won't be random; ports can only conflict with other open ports with the same name. Also a change of IP addresses due to network interfaces being brought up or down can no longer fool YARP into thinking two ports are on different machines when they are actually on the same machine. More accurately, it *could* fool YARP, but won't affect socket number allocation, and so won't lead to conflicts.

Also if you try to register a port name that yarpserver3 believes is already registered, it will ping that port name first to make sure it is gone before giving it to you. And if it is still there, it will not let you register the new port. This avoids accidental reuse of port names. This is a condition that doesn't necessarily cause conflicts (since the programs may be on different machines) but are in some ways worse than conflicts (more confusing).

None of this affects conflict resolution if you do get a conflict, except that I'd really like to hear about the conflict so I can figure out what went wrong! Conflicts should be seen as bugs in yarpserver3, and reported.