Re: Sockets debugging tools

From: Andrei Voropaev (avorop_at_mail.ru)
Date: 02/16/05 

Date: 16 Feb 2005 10:14:52 GMT

On 2005-02-16, T Koster <reply-to-group@use.net> wrote:
[...]
>
> However, since my application uses non-blocking sockets and the select
> system call, I need to be able to test conditions like when send doesn't
> manage to send an entire message, or its buffer fills (through lack of
> or delayed ACKs from the peer due to poor network conditions) and
> reports that it would block. In these cases, my application *should* be
> storing the remaining portion of the message in its own user-space
> buffer to send later, when the select system call says that it's okay to
> send again. Currently I have no way to force this behaviour without
> coding some sort of command to the application protocol almost like
> "ping -f" in behaviour, to try to flood things.

You are wrong. This is perfectly possible by programming your peer not
to read from the socket :) (Emulating the deadlock of the peer). In this
case after the system buffers are filled, your call to send will process
less (or even none) of the data. Note, system buffers are fairly large
so you may need to pass lots of data before they fill up. But they do
fill up. Tested :)

>
> So, there is a possibility that my program is too paranoid about failure
> to send a message by the OS? It is true that almost all sample sockets
> programming code I find on the 'net doesn't seem to worry too much about
> it. I've been trying to read through some IRC server source code, to
> see how they do it, considering they generally handle giant loads, but
> so far they all seem to stem from the same ancient ircd and the code is
> fairly messy and difficult to read. I'll get there eventually. Luckily
> this is a hobby project for me or I would have exceeded a hundred
> deadlines already :)

Well. Your program should be ready to handle any error conditions
returned by recv or send calls. (If you use select, poll or similar,
then you have to watch for error flags there as well). See man 7 tcp,
man 7 ip for the errors. Since TCP is reliable protocol, the only thing
that may prevent it from sending data is an abscence of the route to
peer. You can emulate this either by pulling the network cable out, or
by changing routing tables (not tested :) Anything else in the network
should not be a concern for you. (Though others may prove me wrong :) 

-- 
Minds, like parachutes, function best when open

Relevant Pages

  • Re: Sockets debugging tools
    ... This is perfectly possible by programming your peer not ... >> case after the system buffers are filled, your call to send will process ... and the socket just remains in a permanent would-block state? ...
    (comp.unix.programmer)
  • Re: RMI vs. Sockets vs. ?
    ... RMI is easier than socket programming, ... But sockets can help to connect with application written ... Neglecting for a microsecond the labor cost of creating the apps, by the time you compare the parsing, error-handling and related tasks for a custom message infrastructure against a SOAP-based one with, say Apache and Sun tools, you may find that message sizes are not quite so different, and processing costs closer still. ... Undoubtedly SOAP messages would require more bytes than "equivalent" custom-format compact messages; I'd be dubious of claims that there are significant differences in "speed" once a message reaches its destination. ...
    (comp.lang.java.programmer)
  • Re: C Sockets Newbie: Easy question
    ... If this is an exam question for a sockets course, ... either the file descriptor of the open file (which is a small number ... "Unix Network Programming" by Stevens. ...
    (comp.unix.programmer)
  • Re: Question about CSocket::Receive()
    ... you should not be using synchronous sockets for any purpose. ... It is the nature of TCP/IP that later bytes will not be lost; ... and return the segment up to the terminator; if no terminator was found, ... Receive), etc., but this is all just straightforward programming. ...
    (microsoft.public.vc.mfc)
  • Re: Batch connection to CSKL (was: Trigger CICS transaction from Batch Job)
    ... You can find the fine manual that describes the CICS side of such at z/OS ... in z/OS Communications Server IP Sockets Application Programming Interface ... transaction) that makes managing a listener in CICS quite simple and effective. ... All you need to do is to code the child server transaction in your programming ...
    (bit.listserv.ibm-main)