What happens when connect() fails? #2679
-
|
I have a client (implemented with native C sockets) that tries to connect to a server (implemented with Python) listening on 127.0.0.1. Outside of Shadow, if I start the client without the server running, connect() returns -1 as expected and my client handles it appropriately. Within Shadow (with "model_unblocked_syscall_latency: true"), if I start the client on a host without the server process running, it seems to hang on the connect() call until the simulation ends. I don't see any messages in shadow.log to indicate that these calls are failing. Is this normal? Is there a way to change this behavior? Is there a brief explanation of what's happening? |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 2 replies
-
|
I think you're running into #2162. The calls aren't failing, it's just that the |
Beta Was this translation helpful? Give feedback.
-
|
Typically, you should use non-blocking sockets, and then use |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for the explanation. That's all I need for now; just so I can feel sure of what I'm doing and what's happening under the hood. I think I actually want to move my server process to its own host for other reasons, so it's good to know that it will behave differently that way. A non-blocking call is indeed probably the better answer. |
Beta Was this translation helpful? Give feedback.
I think you're running into #2162. The calls aren't failing, it's just that the
connect()call on localhost never gets a RST response so it blocks forever. It would be nice to fix this, but at the moment we don't want to make too many changes to our TCP code until we start writing a new TCP stack (hopefully in the next couple months). If this is breaking anything for you, let us know and maybe we can re-prioritize it.