Re: Lost data on socket - Can we start over politely?

From: Vorxion (vorxion_at_knockingshopofthemind.com)
Date: 03/31/04 

Date: 31 Mar 2004 05:05:24 -0500

In article <406a9005.0@juno.wiesbaden.netsurf.de>, Thomas Kratz wrote:
>> In short, I think my code is simply lagging behind, and when it lags far
>> enough, the rest of the data vanishes. I'm working on fixing that bit, and
>> I'll also have to prioritize it so that when data is present, it stops
>> working on processing its data internally and goes immediately back to
>> reading from the socket. And I'm simply going to have it scarf up as much
>> data as is present and basically parse and process when there is no
>> actual communication going on. That should (hopefully) elminiate the
>> problem.
>
>That was my guess to, but I couldn't confirm it :-). The problem could be,
>that the TCP buffers of the machine the server runs on, are filled because
>you are draining them too slow, but the client is sending data anyway. I
>didn't use IO::Select on the client with a can_write(), which should take
>care of that ( provided you have control over the client code :-)

The question then becomes whether a non-forking model is viable for
multiple connections if it needs to do processing. I should think so. I
think it's mostly the expense of doing a sysread() of -one- character
about 18 times, and -then- getting bigger blocks, but still not big enough
to make it keep pace--they were only as big as the packets, which were
generally 110chars max.

At which point I probably had far more overhead than it could tolerate when
the client was spewing things forth without delay, even though it was
writing a packet/line at a time. :)

Boy, I never considered the client-side. You're basically saying that the
can_write will actually get the socket equivalent of flow control from the
remote end and only send when it won't get lost? I had always thought for
some reason that the "writable" nature of the select() flags indicated more
the presence of the socket to write to. I didn't know it had -that-
functionality inherent, if I'm reading you correctly. And I do in fact
have control over it. Of course, one writes the server so that it can
handle any client...but I'm ignoring anything that doesn't match my
protocol. :) I just don't want someone to be able to flood it with too
much data and prevent legitimate input from making it.

>> Well, mine is multiplexing--it's meant to take in more than one connection
>> at a time. Yours was written with a single connection in mind, although it
>> demonstrates perfectly that buffering shouldn't be an issue, even at 1k
>> block sizes. The multiplexing is what's complicated mine so much. :)
>
>No. Have you tried it? It handles exactly SOMAXCONN connections.
>The only cause for using the $max_buf variable is preventing one client
>from flooding the server with data and neglecting the other clients.
>If the client data dripples in slowly, one could also use a $max_time
>value (with Time:HiRes) for the maximum time the server processes one
>socket at a time.

Ah, that explains the limitation. Good idea, actually, and I think I'll
keep that then. Actually, do you know if the buffer on the socket is one
single pool, or if each connection to the port has its own buffer? That
goes baack to my other statement about not wanting one attacker to DoS the
whole socket by flooding one fd.

>The foreach loop looks for all readable sockets and handles them. The only
>thing left out is handling a specific timeout for connected client sockets
>without incoming data (could be easily done via a lookup hash with the
>stringified socket values as keys and the time value of the last action on
>the socket as values, shouldn't be more than a few lines).

Yes, I caught the fact that it would take multiple connections. I even
tested it. However, the logging was not multiplexed, where all my protocol
states must be. You weren't differentiating in the log between fd's, but
it was really the proof that the buffering was fine that mattered to me.
The rest is no problem. That was what had me really worried.

I've got it halfway rolled into my code. I separated out the flow into two
loops--one will go as fast and hard as it can to read data (I'm going to
implement the max_buf now that I know why you had it), and the other is for
processing the input, and at every possible pausing point it checks to see
if there is more data to be read and will go back to reading as immediately
as possible if there is. I "just" need to roll in the code that breaks up
the packets from this large internal buffer where I'm storing huge hunks of
code that aren't even analysed. Once I have that, it should hopefully be
fine.

Chances are, nothing in the intended use would stress it anywhere near what
I have been putting it through. Then again, I don't like to take chances.

If I think back to how lousy NFS performance is if you have it set to less
than 8192 byte packets, I should have realised exactly what was going on,
probably. I just didn't think those 15 single-byte reads per packet were
that expensive. And then the small packets on top of it. Ugh. That
pretty much explains it all.

I thank you SO much for your assistance, Thomas! You have no idea how much
relief I feel at this point. I did a brief test of your read methodology
rolled partly into the small sample I had here and it was working 100%
and consistantly. I'm rolling into the real thing now, which is a wee bit
more complicated.

Thank you ever so much! 

-- 
Vorxion - Member of The Vortexa Elite

Relevant Pages

  • Re: How do I tell an object to free up an owned object from thta object itself?
    ... I tested running a sequence of connect/disconnect from the client ... client address for those connections that were active. ... In the ClientConnect event I create a handler object for processing ... >Socket is in fact a TServerClientWinSocket which acts as a end-connection ...
    (comp.lang.pascal.delphi.misc)
  • Re: TCP server stop receiving new connections
    ... reset the event mask of your listening socket each time you ... I have a strange problem in my class library used by all our client ... server applications. ... incomming connections, but keeps current connections. ...
    (microsoft.public.win32.programmer.networks)
  • Re: Lost data on socket - Can we start over politely?
    ... >>you are draining them too slow, but the client is sending data anyway. ... Do I need more than SOMAXCONN simultaneous connections? ... > can_write will actually get the socket equivalent of flow control from the ... It means that your client side send buffer has free space to ...
    (comp.lang.perl.misc)
  • Re: IPTables Port Forwarding
    ... ESTABLISHED and RELATED connections: ... packets will go back through your firewall). ... Then the client gets an answer from "192.168.1.50", ... iptables -t nat -F ...
    (Debian-User)
  • netstat -s output: "packets pruned" and "packets collapsed"
    ... 4087 packets pruned from receive queue because of socket buffer ... 362332 active connections openings ...
    (comp.os.linux.networking)