Sorry for the very late reply and thank you for working on it I built it from the source and tested it with the simple example above
I was expecting it to leave an exception telling that the address was already in use, instead of hanging the process. The behavior now is that the second connection is successful even though the same port was used. When inspecting the system tcp ports with 'netstat -atn', it seems that both are created with a 'double-mapping' (port 50000) (base) marcelo@Lenovo-Legion-5-15IMH05H:~$ netstat -atn Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 0.0.0.0:34463 0.0.0.0:* LISTEN tcp 0 0 127.0.0.53:53 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:50000 127.0.0.1:45794 ESTABLISHED tcp 0 0 192.168.1.5:48216 216.58.202.142:443 ESTABLISHED tcp 0 0 192.168.1.5:55908 3.85.152.15:443 ESTABLISHED tcp 0 0 127.0.0.1:60188 127.0.0.1:59996 TIME_WAIT tcp 0 0 127.0.0.1:45794 127.0.0.1:50000 ESTABLISHED tcp 0 0 127.0.0.1:60192 127.0.0.1:59996 TIME_WAIT tcp 0 0 192.168.1.5:45396 75.2.53.94:443 ESTABLISHED tcp 0 0 192.168.1.5:33528 198.252.206.25:443 ESTABLISHED tcp 0 0 127.0.0.1:43994 127.0.0.1:34859 TIME_WAIT tcp 0 0 127.0.0.1:50000 127.0.0.1:45798 ESTABLISHED tcp 0 0 192.168.1.5:48220 216.58.202.142:443 TIME_WAIT tcp 0 0 192.168.1.5:58644 3.225.183.105:443 ESTABLISHED tcp 0 0 192.168.1.5:48502 216.58.202.142:443 ESTABLISHED tcp 0 0 127.0.0.1:56510 127.0.0.1:34165 ESTABLISHED tcp 0 0 192.168.1.5:43464 52.11.85.228:443 ESTABLISHED tcp 0 0 192.168.1.5:44560 172.217.28.74:443 ESTABLISHED tcp 0 0 192.168.1.5:36802 172.217.28.3:443 ESTABLISHED tcp 0 0 127.0.0.1:45798 127.0.0.1:50000 ESTABLISHED tcp 0 0 127.0.0.1:34118 127.0.0.1:40919 CLOSE_WAIT tcp 0 0 192.168.1.5:51196 107.21.203.251:443 ESTABLISHED tcp 0 0 192.168.1.5:36070 172.217.192.189:443 ESTABLISHED tcp 0 0 192.168.1.5:36662 34.235.68.102:443 TIME_WAIT tcp 0 0 192.168.1.5:37930 172.217.29.229:443 ESTABLISHED tcp6 0 0 127.0.0.1:6942 :::* LISTEN tcp6 0 0 127.0.0.1:63342 :::* LISTEN tcp6 0 0 :::80 :::* LISTEN tcp6 0 0 :::34165 :::* LISTEN tcp6 0 0 :::40919 :::* LISTEN tcp6 0 0 ::1:631 :::* LISTEN tcp6 0 0 127.0.0.1:40919 127.0.0.1:34118 FIN_WAIT2 tcp6 0 0 127.0.0.1:34165 127.0.0.1:56510 ESTABLISHED Is this the intended behavior? Thank you once again Sincerely, Marcelo d'Almeida On Tue, Nov 3, 2020 at 6:10 PM Michael Behrisch <[email protected]> wrote: > Hi, > you are right, this behavior is not useful. I opened a ticket here: > https://github.com/eclipse/sumo/issues/7750. It already has a > preliminary fix but this needs a little more testing. If you like, you > can try the nightly build (showing up tomorrow) or build yourself and > report your findings. > > Best regards, > Michael > > Am 03.11.20 um 18:08 schrieb Marcelo Andrade Rodrigues D Almeida: > > Hi everyone > > > > Trying to open two simulations with the same port hangs the entire > > execution, instead of raising an exception > > > > Error > > "Error: tcpip::Socket::accept() Unable to create listening socket: > > Address already in use > > Quitting (on error)." > > > > > > I'm currently running several experiments, simultaneously, in isolated > > docker containers. And inside every experiment, running several parallel > > simulations > > > > The problem is that my experiments can step (and eventually does) into > > address conflict problems (race condition) and the hanging prevents any > > chance of retrying it with a new port, suspending the entire experiment > > forever. > > > > The use of synchronization locks prevents address conflicts inside one > > experiment, so I'm basically limited to run one experiment at a time, > > which is very time consuming. > > > > > > As a workaround, I'm going to specify port ranges for each simulation > > and check it for availability > > > > Let me know if there is a better solution as workaround > > > > And thank you in advance > > > > > > P.S. I've included a trivial example to show the hanging behavior, but > > there is nothing special about it. > > > > > > Sincerely, > > > > Marcelo d'Almeida > > > > _______________________________________________ > > sumo-user mailing list > > [email protected] > > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/sumo-user > > > > > _______________________________________________ > sumo-user mailing list > [email protected] > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/sumo-user >
_______________________________________________ sumo-user mailing list [email protected] To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/sumo-user
