Re^2: IO::Socket connect fails to block

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)
[download]

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 ...

Comment on Re^2: IO::Socket connect fails to block Download Code

Replies are listed 'Best First'.
Re^3: IO::Socket connect fails to block by mr.nick (Chaplain) on Jan 18, 2012 at 13:42 UTC
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 ...	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^3: IO::Socket connect fails to block
by mr.nick (Chaplain) on Jan 18, 2012 at 13:42 UTC

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 ...

[reply]
[d/l]
[select]