All recv() calls will wait for data to be available (unless you ioctl the file descriptor to make it non-blocking), and all of them return before the read buffer is filled if no more data is available. If you don''t like this, you can pass the MSG_WAITALL flag to recv(), it''ll then wait for the buffer to be filled (or a signal or similar to occur).

The standard behaviour is usually the most useful. Imagine a server listening on a TCP port, e.g. a webserver. It waits for commands from the client (in the web-server case the most common one is GET url protocol). Now the server calls recv(), with a pretty big buffer - using a small buffer would be pretty stupid as it might force several reads until you get to see the complete command.
But of course hardly any command will be as long as the buffer - so if the recv() waited, it''d never return and the connection would eventually time out.

read() will always return only as much data as is available (unless nothing is available). This is true for everything ranging from pipes over sockets (which are essentially pipes) to standard files.

cu,
Prefect

---
Sanity is the trademark of a weak mind.

Also, take note that linux (and all unix/bsd/ect operating systems) use files for everything while windows does not (its a really crap o/s). You can use the read/write ansi commands to send and receive data over a socket just as you would a file but only in linux operating systems and not windows. While linux uses a standard int (aka long/32-bit) to keep track of a socket like any file, windows uses a specail type called SOCKET which is derived from an int but has nothing to do with files. They are merely handles to sockets, if you want to maintain portability to windows you cant use read/write to send/recv from sockets.

What I'm doing is setting up send/receive calls in pairs. There is one header packet that defines the proceeding packet's type, size, etc.

Sort of like ...


int ReceivePacketHeader();


... which receives a packet header for identification. The packet header contains things like the proceeding packet's type, client ID, size (for verification purposes), time that the file was sent, and so on. Then the client attempts a receive as such ...


int ReceivePacket();


... which contains a large switch statement using the type obtained from the first ReceivePacketHeader()'s function's call to know what exactly the server is trying to send to the client.

Both client and server use code from the same .h/.cpp files.

Anyone see any potential downfalls of this sort of system? Note that I'm not looking for something elegant or fast at this point, just something reliable.


MatrixCubed
http://MatrixCubed.org

Edited by - MatrixCubed on February 25, 2001 11:32:28 AM