Re: socket programming

Hello Sirisha,

On Thu, 8 Jun 2006 11:55:46 UTC, "sirisha" <sirishamohan2000@gmail.com> wrote:


TCP/IP and other protocols are usually very time dependant. The API
behavior is predictable, but the exact sequence of actions required
for a given action may not be. That is, you can look up the connect()
function and find all of the various return codes that are supported.
However, just because you think you know the state of your system,
doesn't mean that an unexpected, but defined, return code won't happen.
For example, you may want to send() a large chunk of data. You cannot
predict how many calls to send() may be required because the amount of
data transferred with each call may change. This is normal even for
production software. TCP/IP attempts to tune its performance based
on the data sizes transferred and the retry attempts requested by
lower communciation levels.

Problem areas may be difficult to diagnose becuase any attempt to
watch applications communicate may actually change their behavior.
For instance, you've stated that during a debugging session your
code appears to work just fine. Yet during a non-debugging
session your code may misbehave. The very act of stopping your
code at certain points and watching for certain states may
actually prevent them from happening. A good example of this
is stopping your sending thread at each call and never once
receiving the status for "queue-full, please wait". Yet the
free running sending thread could get this status after the
first couple of sequential send requests.

I don't know what compiler and operating system you are using
so I can't tell you all of the possible return codes. Each
implementation of the socket interface may have slightly
different implementations. You will need to look up the
return codes and their meanings in your documentation.
Quite often the status codes are at least mentioned as a
group in a single .h file. Most non-Microsoft (Unix based)
TCP/IP implementations have documentation that will list
all of the possible return codes and behaviors for each
socket API function. Microsoft tends toward one global
mess of status codes and their documentation often doesn't
list all of them (if any) combined with the socket API
functions.

Let me do a quick 'google' for you. Back in a minute.

Okay, concatenate the following three lines together and
look them up with your browser.

http://msdn.microsoft.com/library/
default.asp?url=/library/en-us/
winsock/winsock/recv_2.asp

This is one of the Microsoft web pages that documents
the functionality of the recv() function. It may not
be exactly what you need, but it should give you a
good idea what to look for in your own compiler/OS
documentation.

Notice what is said about the return value. Basically
there are three values: positive is length sent,
0 means connection closed, and a certain negative
value is an error. You have to ask for the actual
error via another call... WSAxxxGetLastError().
In Unix derived APIs, you may look at errno
or perhaps the negative value will indicate the
error.

Looking at their list of possible errors you'll
see what some of the errors actually mean.

Also notice that there isn't an error for
not sending your complete message. You may
have requested a send() for 1000 bytes and
received a return value of 518. So even if
no error was returned you still have to check
the return value to see if a partial send
occurred and that you would need to send the
remaining (1000-518) bytes.

I didn't find a good example for you. Sorry
about that. Here is a short, incorrect
example that you might get an idea from.

{
  ...
  // send message to server
  int SendLength = 0;
  char SendBuffer[];
  
  ... fill SendBuffer and SendLength with the correct values

  while (SendLength > 0)
  { // while there is data to send; send it
     const int BytesSent = send (socket, SendBuffer, SendLength);

     if (BytesSent < 0)
     { // error occured; find out what and tell the user
        ...

        break;
     }
     else if (BytesSent == 0)
     { // No bytes sent; make sure there wasn't an error
        if (...)
        { // report any error that occurred
           ...

           break;
        }
     }
     else
     { // some data was sent
        if (BytesSent <= SendLength)
        { // successful send; advance to next send point
           SendLength -= BytesSent;
           SendBuffer += BytesSent;
        }
        else
        { // What happened? More bytes were sent than expected
           // the developer or the API did something wrong,
           // report it!
           
           ...

           break;
        }
     }
  }

  // the complete message was sent successfully
  // unless an error was reported
  ...
}

It is sometimes best to simplify your code with many
utility functions/methods. For instance, something
like the above could be a SendMessage() function.
It could be used anywhere in your application where
you wanted to send a complete message to a single
socket without any other actions being performed.

There are ways to interleave many read/write
operations across many sockets and have a single
thread/process control them. It takes a bit more
work, but the basic ideas are all the same.
The select() function can be used to ask the
socket API which socket(s) have data waiting to
be read, which socket(s) can be written to,
and which socket(s) are currently have an error
to report.

Once you do the hard part of writing the various
helper functions that you think you will need,
they can be reused for further projects. You
might even create a prototype client or server
at some point. Certainly C++ and other OO
capable languages allow you to build deep,
useful communication classes.

Hint: Two of my derived classes from many years
ago are named: ISMTPClient and ISMTPServer.
Each was derived from IClient and IServer.

You aren't that far from creating correct versions
of your helper functions. It just takes a bit more
reading and deciding what it is you want to build.
Like many other ideas, the second time you need
them they are much easier to create or reuse older
code. When we've done this enough times we sometimes
build lots of utility functions and classes that we
carry around with us.

Keep at it. I'll be watching to see how you are
progressing.

Good night,

David