Jim Brain

I still think there's a race condition in VICE, but I've no specific issue with closing the ticket.

And yes, if you can do a blocking shutdown, that would easily alleviate the problem. Still chatty...

In a situation where you're only willing to accept X connections, where X = 5 or 20 or 100, I think ignoring some is more valid. When X is 1, it gets trickier and harder to debug. This should not require any serial hardware, as it's completely virtual. tcpser 1.1.4 should be dloaded, compiled, and run as tcpser -l 7 -tsSiImM -v 25232 VICE should be run, and rs232 port should be set to IP and connect to localhost:25232 Then, load and run some rs232 app, I would assume (I think a terminal app or a...

I do it to be more deterministic in logging. In this case, the logs were very helpful in noting additional connections were coming in. As well, I think the comer TCP/IP book sets a best practice to always accept incoming connections on a server socket and do something with it, as opposed to just letting it linger there (I'm not sure where you'd have to go to see that un-accepted connection, I assume in some Windows event log or the low level sockets event log in Linux). That dates me, as I learned...

As shown in this diagram: https://www.geeksforgeeks.org/tcp-connection-termination/ Closing a connection is a multi-step process. The client (VICE in this case), starts the close process by calling the socket close() function, but that just sends the FIN command to the received (tcpser in this case). tcpser is not notified of this reception, as the underlying sockets subsystem then sends a ACK for the FIN and it's own FIN back to the client, which is then handled by the underlying client sockets...

I can't provide the VICE flags (someone else will need to provide), but the kludge I made is: If VICE connects to tcpser and then tries to connect AGAIN to tcpser, in the kludge version I drop the original connection and sue the new connection. I suspect the issue is in: https://sourceforge.net/p/vice-emu/code/HEAD/tree/trunk/vice/src/rs232drv/rs232net.c I'd instrument this code a bit more to see how many times reset or close is called in a normal startup of a BBS app like Image BBS. What I am seeing...

I also think this issue is OS related. It appears Al is able to run with 1.1rc2 on Windows just fine (Windows TCP/IP subsystem may dispatch connection info differently), but not on Ubuntu Linux

The issue is not a code regression, but a latent race condition. It appears VICE opens a connection to tcpser's ip232 listener, and then later opens a different connection to the same listener. In the v1.0rc12, evidently the code compilation manages to see the connection close before the second connection attempt in made, while the 1.1rc2 sees the second connection before it can see the first time out. 1.0rc12 logs: 2020-11-07 22:40:47:-364824832:INFO:Connection accepted from 127.0.0.1 2020-11-07...