My reason for wanting to do this would be to allow the server, which sends the initial message, waits for a response to move on to the next message. If I did this in a single thread, everything would work fine.
My only concern was to be able to handle the case were the "client" closed the connection when there were no more messages pending. Since the server only does an SSL_read after sending a message, it would never receive the close-notify until another message became available. For some clients, the time between messages might be days.
Since I need to detect dead clients, I considered the use of keep-alives. This would give me a write/read cycle that should reap a close-notify if one is pending.
My other thought (which has been dashed to pieces with this discussion thread) was to have a single global reader thread to receive potential close-notifies.
Since my message server will have potentially thousands of simultaneous connections, the last thing I want to do is switch to a non-blocking/polling style. (I would prefer a lot of threads blocked on I/O than a few threads spinning in circles.)
Any suggestions?
On Jan 5, 2004, at 5:22 PM, Frédéric Giudicelli wrote:
Right on !
May I ask a silly question?
Why would you do such a weird thing in the first place? (maybe we should
have started from there) :)
Frédéric Giudicelli http://www.newpki.org
smime.p7s
Description: S/MIME cryptographic signature
