problem w/server that accepts reads and writes w/select

[minesh]

I have created client server code. My clients either send data to the server or receives data from the server. The server uses the SELECT command to multiplex between the connections. My intent is when a client CONNECTS to the server in order to send it data, I expect the bits in readfds to reflect that and I can have the server responds with a read. If a clients CONNECTS to the server in order to receive data, I expect the bits in writefds to reflect that and I can have the server responds with a write.

But no matter what my client wants to do on a CONNECT, the readfds bits are always set. So my code in response to writefds does nothing.

Have I misunderstood how the writefds and readfds bits are used? Can someone give me a clue what I am doing wrong?

Thanks

Minesh

[RobSeace]

No, select() doesn't work the way you're thinking it does...
It will show an FD as readable if there is any data in the receive
queue... And, it will show an FD as writable if there is any free
space in the send queue... (So, under normal conditions, it'll
generally show most FDs as ALWAYS writable...)

What FD are you select()'ing on in the server? The listening
FD, or the connected FD you receive from accept()? If the former,
then yeah you'll always see that as readable when a new client
connects... In the case of a listening socket, readability just
means there are unaccepted clients in the listen queue... (And,
I don't think writability means much of anything...) But, in the case
of a connected socket (eg: one received from accept()), select()
should only show it readable if the client sent some data for you
to read... (But, it'll always show as writable, unless you fill up your
send queue...)

Quite honestly, I find the writability testing of select() to be pretty
much completely useless, most of the time... I rarely ever have
any use for it, at all... But, readability testing is extremely
useful...

[minesh]

Thanks.

Yup...it looks like you are right. I initially use the SELECT to look at the listening FD. On CONNECT by a client, this FD is set and I build a connection FD list with the ACCEPT FD. Standard stuff. I then read and write on the ACCEPT'ed FD. However, I SELECT on the lister FD as well as the FDs in the connection list. So, I thought if I placed those same FDs in the readfd and writefds, I could sense what client wanted to read and what client wanted to write.

But, in my case, the writefd doesn't isn't getting set ever. Funny thing is that if I have one client connect and then block on a read, I would expect that the accpted FD by the server would be writeable and the writefd would inicate that. But nope.

Basically, what I am trying to do is have the server who responds to writes by client A and based on the received data, also relay that data to client B who is waiting for data.

[RobSeace]

So, FDs are never select()'ing as writable? That seems odd
to me... I would think they should pretty much ALWAYS select()
as writable (unless the send queue was filled, as I said)...

But, in any event, I don't think you're going to be able to use it
as a way to tell who is waiting to have data sent to them... Your
best approach is to build something into the protocol, where the
clients inform the server via some message that they are waiting
for data, or something along those lines... You can tell when
clients have sent you data, but you can't tell when they're waiting
for you to send them some... It really has to be part of the agreed
upon protocol, somehow...