Beefy Boxes and Bandwidth Generously Provided by pair Networks
Syntactic Confectionery Delight
 
PerlMonks  

Re: IO::Socket connect fails to block

by gman (Friar)
on Jan 06, 2012 at 19:21 UTC ( [id://946652]=note: print w/replies, xml ) Need Help??


in reply to IO::Socket connect fails to block

Shouldn't reuse be set to null?

ReuseAddr Set SO_REUSEADDR before binding Reuse Set SO_REUSEADDR before binding (deprecated, prefer ReuseA +ddr)

Update: I tried you above code and it works as expected, printing out any lines "queued" up from the second client.

Replies are listed 'Best First'.
Re^2: IO::Socket connect fails to block
by mr.nick (Chaplain) on Jan 06, 2012 at 19:42 UTC
    Tried that; no change in behavior. To shed a little light on the actual issue I'm having, consider this scenario:

    1. A single threaded/noforking server is running.
    2. Two clients are constantly connecting to it, sending TWO lines of text each time, then waits for a response.

    What happens is that the first client to connect sends it's two lines, gets it's response, and continues. The second client connects, sends it's two lines, BUT when the server finishes the first client and moves onto the 2nd client, it only sees ONE line of text.

    Here's some output that may or may not help:

    client 1: 2012-01-06-14.32.08 [Collection..:ConnectToDispatch 184] Connecting +to dispatch at 127.0.0.1 .... 2012-01-06-14.32.08 [ CS_Server.pl 175] Consulting +Dispatcher 2012-01-06-14.32.08 [Collection..twork::SendMessage 118] Sending REQ +UEST_TYPE (10) 2012-01-06-14.32.09 [Collection..ork::SendSocketRow 160] Sent socket + row COLLECTION 2012-01-06-14.32.10 [Collection..RecvAndValidateMsg 130] Received me +ssage ACK_REQUEST_TYPE client 2: 2012-01-06-14.32.13 [Collection..:ConnectToDispatch 184] Connecting +to dispatch at 127.0.0.1 .... 2012-01-06-14.32.13 [ CS_Server.pl 175] Consulting +Dispatcher 2012-01-06-14.32.13 [Collection..twork::SendMessage 118] Sending REQ +UEST_TYPE (10) 2012-01-06-14.32.14 [Collection..ork::SendSocketRow 160] Sent socket + row COLLECTION server (first client): 2012-01-06-14.32.06 [Collection..CP::AcceptListener 64] Accepted co +nnection from 127.0.0.1:1866 (IO::Socket::INET=GLOB(0x1033f3d8)) >>> message is '10 ' 2012-01-06-14.32.06 [ Collection::IPC::TCP::Receive 155] Received '1 +0' from IO::Socket::INET=GLOB(0x1033f3d8) >>> message is 'COLLECTION ' 2012-01-06-14.32.07 [ Collection::IPC::TCP::Receive 155] Received 'C +OLLECTION' from IO::Socket::INET=GLOB(0x1033f3d8) 2012-01-06-14.32.07 [Collection..er::ProcessRequest 90] Received re +quest type of 'COLLECTION' 2012-01-06-14.32.07 [ Collection::IPC::TCP::Send 167] Sending '15 +' to IO::Socket::INET=GLOB(0x1033f3d8) server (2nd client): 2012-01-06-14.32.11 [Collection..CP::AcceptListener 64] Accepted co +nnection from 127.0.0.1:1872 (IO::Socket::INET=GLOB(0x103f1278)) >>> message is '10 ' 2012-01-06-14.32.11 [ Collection::IPC::TCP::Receive 155] Received '1 +0' from IO::Socket::INET=GLOB(0x103f1278)
    No "Received 'COLLECTION'" from that point.

    So it appears to me that when a client hasn't been "accept"ed and sends multiple lines of text, only one is being received when it eventually is connected.

    That's my issue. I'll continue to go over my code again and see if I'm not doing something stupid, but honestly this is confusing me.

    mr.nick ...

      Just to comment and provide some closure to this, in case anyone looks, recall that my seeming issue was this:

      1. Client connects to server and does some i/o
      2. 2nd Client attempts to connect to server and do some i/o. It spews a few lines of text at the socket and waits.
      3. Server finishes with client #1, accepts() client #2
      4. Not all the text send over in #2 is there.

      Well, this is under Windows (Cygwin to exact) and I found the issue... during the negotiation between client and server multiple debugging output is done. In the DebugMsg() function is the following:

          chomp(my $d = `date "+%Y-%m-%d-%H.%M.%S"`);

      That is the culprit. Shelling out and running date is somehow flushing/truncating the sockets. A simple change from that to

              my $d = strftime("%Y-%m-%d-%H:%M:%S",localtime(time));

      Completely fixed my issue.

      Pain in the ass, eh?

      mr.nick ...

Log In?
Username:
Password:

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

How do I use this?Last hourOther CB clients
Other Users?
Others musing on the Monastery: (5)
As of 2024-04-18 19:32 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found