I am currently working on a small LAN-based IM program. I'm mainly doing this just "because", but also as a replacement for WinPopUp/LinPopUp. I've looked into Jabber, and it just seems like "too much" for our needs. I mean, at most there will be a couple of dozen users.

In any case, I've been using select to handle the clients, but have run into what I feel is a huge bug waiting to happen.

In essence: After a select, I go into a read() loop, reading until I get an expected number of bytes. Well, it seems to me that this would leave the SERVER hanging if a client said it would said 500 bytes then only sends 400. It would be trying to read for 100 more bytes.

The only thing I can think of is to read into buffers, just one chunk at a time. Of course, then I need to rewrite all of my code to go into these buffers. And I'd need buffers that dynamically expand/contract, with the buffer essentially moving through memory. (realloc, perhaps, but I don't know how to make realloc reallocate to a new base of ptr+2048 bytes or whatever)

Essentially, I'll need to rewrite 50% of the 1000 lines of code I have written. I realize I should've seen this coming in the design phase, but this is the first time I have ever written anything using select() on sockets. All my previous network programs have fork()ed a separate child for every request.

So, I guess I'm looking more for thoughts on design than specific code. Or a way to make read() timeout, after, say 5 seconds... this would limit the hang to 5 seconds, then DISCONNECT the offending client.

See Beej sockets tutorial it has an exaple of doing that
http://www.ecst.csuchico.edu/~beej/guide/net/

If you use read, only a number of bytes that's available (in your case: received) is read. read() reads from a system buffer, so there should not be a problem with waiting for the other side.

If you don't have the number of bytes you want, your program should go back to select() which will stop when something new was received.

I wonder how you know how many bytes to expect. It should be a control message, I can't see a different method. So you can allocate buffer for the whole message you expect and have a list of such buffers (one for client). If you also keep the size that's filled, you can easily append new data until you have what you want.

Unless you've set the file descriptor non-blocking with fcntl(), or select() has returned the file descriptor as ready for reading and there haven't been any read()s on the descriptor since then, read() may block.

Matir's options are a multiplexing model with buffers for each client, or concurrency with either processes or threads. If what one client does doesn't matter to other clients, a fork()ing model will be easy. Otherwise, you want to go with threading or multiplexing. If you haven't programmed using threads before, you should probably stick to multiplexing since you're already learning something new for this project.

I've been using Beej's tutorial all along. It's great.

Since the clients MUST interact, I guess I'm limited to the mulitplexing model, so I'll be rewriting the codebase. *sigh* At least I'm learning.