Thank you for the clarification

After trying the original test with version 1.8.0, I still receive the same
error
(that somewhat differs from the simple test as it is also accompanied by
"unpack requires a buffer of 4 bytes" error)

Perhaps the original problem is other than the simple test was reproducing.

See attached log with the noticed behavior.

Is there anything I can try to test what the cause is and make it easily
reproducible?

This behavior is happening in a fairly complex application (few parallel
simulations created several times) with docker executions on a ubuntu
remote server.


Thank you in advance


Sincerely,

Marcelo d'Almeidas

On Fri, Nov 27, 2020 at 1:45 PM Michael Behrisch <[email protected]> wrote:

> Hi,
> yes it is the intended behavior. We noticed that there is no point in
> leaving the port open once all clients have connected. So we just close
> it and it is available to be used again. This should also help in
> avoiding conflicts since the ports are not open very long.
>
> Best regards,
> Michael
>
> Am 26.11.20 um 13:02 schrieb Marcelo Andrade Rodrigues D Almeida:
> > 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 <http://0.0.0.0:34463>
> > 0.0.0.0:*               LISTEN
> > tcp        0      0 127.0.0.53:53 <http://127.0.0.53:53>
> > 0.0.0.0:*               LISTEN
> > tcp        0      0 127.0.0.1:631 <http://127.0.0.1:631>
> > 0.0.0.0:*               LISTEN
> > tcp        0      0 127.0.0.1:50000 <http://127.0.0.1:50000>
> > 127.0.0.1:45794 <http://127.0.0.1:45794>         ESTABLISHED
> > tcp        0      0 192.168.1.5:48216 <http://192.168.1.5:48216>
> > 216.58.202.142:443 <http://216.58.202.142:443>      ESTABLISHED
> > tcp        0      0 192.168.1.5:55908 <http://192.168.1.5:55908>
> > 3.85.152.15:443 <http://3.85.152.15:443>         ESTABLISHED
> > tcp        0      0 127.0.0.1:60188 <http://127.0.0.1:60188>
> > 127.0.0.1:59996 <http://127.0.0.1:59996>         TIME_WAIT
> > tcp        0      0 127.0.0.1:45794 <http://127.0.0.1:45794>
> > 127.0.0.1:50000 <http://127.0.0.1:50000>         ESTABLISHED
> > tcp        0      0 127.0.0.1:60192 <http://127.0.0.1:60192>
> > 127.0.0.1:59996 <http://127.0.0.1:59996>         TIME_WAIT
> > tcp        0      0 192.168.1.5:45396 <http://192.168.1.5:45396>
> > 75.2.53.94:443 <http://75.2.53.94:443>          ESTABLISHED
> > tcp        0      0 192.168.1.5:33528 <http://192.168.1.5:33528>
> > 198.252.206.25:443 <http://198.252.206.25:443>      ESTABLISHED
> > tcp        0      0 127.0.0.1:43994 <http://127.0.0.1:43994>
> > 127.0.0.1:34859 <http://127.0.0.1:34859>         TIME_WAIT
> > tcp        0      0 127.0.0.1:50000 <http://127.0.0.1:50000>
> > 127.0.0.1:45798 <http://127.0.0.1:45798>         ESTABLISHED
> > tcp        0      0 192.168.1.5:48220 <http://192.168.1.5:48220>
> > 216.58.202.142:443 <http://216.58.202.142:443>      TIME_WAIT
> > tcp        0      0 192.168.1.5:58644 <http://192.168.1.5:58644>
> > 3.225.183.105:443 <http://3.225.183.105:443>       ESTABLISHED
> > tcp        0      0 192.168.1.5:48502 <http://192.168.1.5:48502>
> > 216.58.202.142:443 <http://216.58.202.142:443>      ESTABLISHED
> > tcp        0      0 127.0.0.1:56510 <http://127.0.0.1:56510>
> > 127.0.0.1:34165 <http://127.0.0.1:34165>         ESTABLISHED
> > tcp        0      0 192.168.1.5:43464 <http://192.168.1.5:43464>
> > 52.11.85.228:443 <http://52.11.85.228:443>        ESTABLISHED
> > tcp        0      0 192.168.1.5:44560 <http://192.168.1.5:44560>
> > 172.217.28.74:443 <http://172.217.28.74:443>       ESTABLISHED
> > tcp        0      0 192.168.1.5:36802 <http://192.168.1.5:36802>
> > 172.217.28.3:443 <http://172.217.28.3:443>        ESTABLISHED
> > tcp        0      0 127.0.0.1:45798 <http://127.0.0.1:45798>
> > 127.0.0.1:50000 <http://127.0.0.1:50000>         ESTABLISHED
> > tcp        0      0 127.0.0.1:34118 <http://127.0.0.1:34118>
> > 127.0.0.1:40919 <http://127.0.0.1:40919>         CLOSE_WAIT
> > tcp        0      0 192.168.1.5:51196 <http://192.168.1.5:51196>
> > 107.21.203.251:443 <http://107.21.203.251:443>      ESTABLISHED
> > tcp        0      0 192.168.1.5:36070 <http://192.168.1.5:36070>
> > 172.217.192.189:443 <http://172.217.192.189:443>     ESTABLISHED
> > tcp        0      0 192.168.1.5:36662 <http://192.168.1.5:36662>
> > 34.235.68.102:443 <http://34.235.68.102:443>       TIME_WAIT
> > tcp        0      0 192.168.1.5:37930 <http://192.168.1.5:37930>
> > 172.217.29.229:443 <http://172.217.29.229:443>      ESTABLISHED
> > tcp6       0      0 127.0.0.1:6942 <http://127.0.0.1:6942>
>  :::*
> >                     LISTEN
> > tcp6       0      0 127.0.0.1:63342 <http://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 <http://127.0.0.1:40919>
> > 127.0.0.1:34118 <http://127.0.0.1:34118>         FIN_WAIT2
> > tcp6       0      0 127.0.0.1:34165 <http://127.0.0.1:34165>
> > 127.0.0.1:56510 <http://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]
> > <mailto:[email protected]>> wrote:
> >
> >     Hi,
> >     you are right, this behavior is not useful. I opened a ticket here:
> >     https://github.com/eclipse/sumo/issues/7750
> >     <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] <mailto:[email protected]>
> >      > To unsubscribe from this list, visit
> >     https://www.eclipse.org/mailman/listinfo/sumo-user
> >     <https://www.eclipse.org/mailman/listinfo/sumo-user>
> >      >
> >
> >
> >     _______________________________________________
> >     sumo-user mailing list
> >     [email protected] <mailto:[email protected]>
> >     To unsubscribe from this list, visit
> >     https://www.eclipse.org/mailman/listinfo/sumo-user
> >     <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
>

Attachment: error
Description: Binary data

_______________________________________________
sumo-user mailing list
[email protected]
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/sumo-user

Reply via email to