Beefy Boxes and Bandwidth Generously Provided by pair Networks
go ahead... be a heretic
 
PerlMonks  

Re: IO::Socket connect fails to block

by zwon (Monsignor)
on Jan 07, 2012 at 03:46 UTC ( #946709=note: print w/ replies, xml ) Need Help??


in reply to IO::Socket connect fails to block

When client calls IO::Socket::INET->new it sends to server TCP packet with SYN flag in it. Since given TCP port on server is in LISTENING state, server immediately replies with SYN,ACK, it is done by kernel, and it doesn't matter that your application is not blocked in accept(2). After receiving SYN,ACK client side treats connection as ESTABLISHED, at this moment connect(2), and consequently IO::Socket::INET->new return. Also client sends ACK to server, upon receiving this ACK server either ignores it if application listen queue is full, or assumes connection ESTABLISHED and places it into application queue, again it doesn't matter what application is doing at the moment. Application queue size is determined by Listen parameter (though maybe not exactly equal to it, e.g. on BSD derived systems if you set Listen to 0 queue size will be 1), which in your case is quite big. Note, that changing Listen doesn't affect client's behaviour, as this parameter is taken into account only upon receiving ACK from client, at which stage client already thinks it is connected.

So, your scripts work exactly as I expect.

P.S.: Given description is valid for modern Linux and may be slightly different on other systems.

P.P.S.: generally you shouldn't bother if server already accepted connection or not, you can just start using socket returned by IO::Socket::INET->new, if connection is not yet accepted you will be blocked in recv(2) or send(2) at some point later.


Comment on Re: IO::Socket connect fails to block
Select or Download Code
Re^2: IO::Socket connect fails to block
by cavac (Chaplain) on Jan 07, 2012 at 13:12 UTC

    Given description is valid for modern Linux and may be slightly different on other systems.

    I agree. Depending on whatever crappy windows version one uses, blocking sockets may not block or non-blocking sockets may block. And there's a difference between blocking while communicating and blocking while waiting for a new connection.

    For me, it was always a bit confusing when switching between Windows and Linux - or to be more precise developing basic TCP connections anywhere. I "fixed" this PEBCAC problem by switching to HTTP whenever possible. In my case, this usually means HTTP::Server::Simple::CGI or Maplat on the server and something like WWW::Mechanize::GZip on the client.

    Of course, this is only my small, personal development universe, yours may have different requirements and bugs or a even better developer altogether...

    "Believe me, Mike, I calculated the odds of this succeeding against the odds I was doing something incredibly stupidů and I went ahead anyway." (Crow in "MST3K The Movie")

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://946709]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others imbibing at the Monastery: (3)
As of 2014-07-26 05:43 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (175 votes), past polls