Sebastian Treu: > As David said in an older thread, I can think of the API as a state > machine and then, regarding how much progress we get, do something. > Considering this, I have some doubts about a communication between > server and clients. Let's say we write a client that in his nature, > it's not a desired client. But, he connects, he handshakes and he > authenticates, and he behaves improperly. For example, when the server > sends him the data he required, he doesn't read it.
You always have to consider that. Even if the client is not malicious, the data might not get there, the machine might crash, the network can go down. This can always happen. > (I forgot to mention the use of non-blocking I/O) > A break here in that scenario: SSL_write() will not make further > success on writting to that client and SSL_get_error() will yield > WANT_WRITE or WANT_READ and we can use select() to decide which action > must be taken. Exactly. > If this is correct, I have some doubts about how to > implement a server that does overcome this issue with large amount of > data without letting the others clients hang in for the timeout we can > set on select() for example. You seem to have lost the point of non-blocking I/O. The point is that you *NEVER* block, and therefore *NEVER* shut out other clients. If there's some other way you can make forward progress, *definitely* don't call 'select'. Make forward progress elsewhere. It's only when you cannot make forward progress *anywhere* that you call 'select' (or 'poll'), because there's nothing else you can do. And then you must 'select' or 'poll' on every client you have and your 'listen'ing sockets as well. > I want to avoid the timeout because i'm > not pretty sure which value to use as we are communicating through a > network and I think that using small values could lead to avoid a > client that is slow on receiving data (I could be wrong in this > thinking). It makes no difference what value you use, so long as there is nothing else you can do. If there's something else you can do, well why aren't you doing it?! > Others things are to instantaneously put that client in a wait list > when SSL_write() could not succed, continue with the others, and try > with that client again later. But, sometimes we can get a WANT_WRITE > or WANT_READ when renegotiating so this does not appears a solution. I don't follow. Why is that not a solution? > That "zombie client" thing makes SSL_write() "block". So, if the > client we are sending data does not read it, do we have some especial > error, function or something that the API provides us? Or do we think > on a workaround for it? You just go on and do other things. There should be nothing special you need to do. > Maybe this sound like an implementation issue, but in fact I didn't > find information that tell us this scenario. I read on the possibility > of using the error pending on select() and the sockets error but no > one seems to be useful (at least for me) on this issue. This is not an error case. This is how servers work -- they do work on each client when they need it. You have to go out of your way to make this a problem. Basically, a 'select' loop server operates as follows: 1) Open any 'listen'ing sockets we need. 2) Call 'select' or 'poll' for any operations we might be able to do. 3) For every 'select' or 'poll' hit, make as much forward progress as possible. 4) Go to 2. You *never* block on only one thing. You *always* block on every possible thing that might cause you to have to do more work. DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
