Thread: Forwarding client data

G'day,

I'm writing a small proxy. Basically I spawn a thread for each client that connects, and use blocking sockets (with timeouts) to service the client.

However, with that approach I've run into a snag. Basically my pseudo code is:

Code:

while(client or server connection open)
{
   buffer = read_from_client()
   send_to_server(buffer)

   buffer = read_from_server()      /* blocks here */
   send_to_client(buffer)
}

However, the server doesn't want to send me any data yet. Since it's waiting for the full client request. So the call basically blocks forever.

I've thought of peeking at the server socket to see if there's any data to read, and skipping it if not. However, MSG_PEEK has bad performance. Even though I'm only targeting around 64 client threads at a given time.

So what would be the suggested route here? I could peek, or multiplex between the client and server socket (i.e. with select())? But I'm sure that would hurt performance (each thread would then need to multiplex.

[edit]
MSG_PEEK isn't an option. It's recommended against using it in Winsock (I'm targeting Windows and Linux).
select() or poll() aren't really options.
Could I just use non-blocking sockets in a loop? Although that may mean I'm using a lot of CPU just to see if data arrived.
[/edit]
Thanks!
Zac

> select() or poll() aren't really options.
Why not?
select() is available on both systems.

The only downside to select() on windows is that it can ONLY be used for socket descriptors.

And why block? The only time blocking sockets are an option is when you are guaranteed fast turn-around on server accesses...

Originally Posted by jeffcobb

And why block? The only time blocking sockets are an option is when you are guaranteed fast turn-around on server accesses...

So I *should* ditch the treading model and switch to non-blocking sockets?

Originally Posted by Salem

The only downside to select() on windows is that it can ONLY be used for socket descriptors.

And MSDN recommends against it, because performance is poor.

But is it
a) actually that bad in this case?
b) a reason to tie yourself to their 'higher performance' solution?

Or you could go threads and one blocking socket per thread, and let the threading mechanism sort out the waiting game. But no doubt that comes with baggage as well.