Beefy Boxes and Bandwidth Generously Provided by pair Networks
P is for Practical

Re: IO::Socket connect fails to block

by zwon (Abbot)
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.

Replies are listed 'Best First'.
Re^2: IO::Socket connect fails to block
by cavac (Deacon) 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?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://946709]
[Corion]: Also, I think the OPs problem is on their intranet and not on the internet (also, they should likely use WWW::Mechanize instead, which knows about cookie)
[1nickt]: yes, could be.
[1nickt]: I don;t see the link , definitely, after reloading the node
[1nickt]: Is it possible to disable it?
[Discipulus]: if you mean [download] after the code it is there 1nickt
[1nickt]: yes, Corion sees it too, and I see it when not logged in.
[Corion]: I think you can disable download links in your settings?
[1nickt]: Looking in settings to see if I disabled it in my profile ...
[1nickt]: There is "Don;t show embedded d/l links" in Display settings. It is unchecked.
[1nickt]: Oh, there is a minimum lines setting!

How do I use this? | Other CB clients
Other Users?
Others chilling in the Monastery: (9)
As of 2017-05-23 18:19 GMT
Find Nodes?
    Voting Booth?