yermej
8/30/2007 9:29:00 PM
On Aug 30, 3:20 pm, "yer...@gmail.com" <yer...@gmail.com> wrote:
> I'm working on an SSL client/server application using persistent TLSv1
> connections. I'm having some issues with my server and what I think
> should be a blocking read or select.
>
> I'm basically doing this where @io is an OpenSSL::SSL::SSLSocket:
>
> until @data.length == READ_SIZE do
> tmp = @io.read(READ_SIZE - @data.length)
> if tmp.nil?
> IO.select [@io]
> else
> @data << tmp
> end
> end
>
> (I did not initially have the select call, but decided to give that a
> try.)
>
> I would expect that the read would block (I have not set O_NONBLOCK on
> the socket) until there is data to be read. Instead, when there is no
> data, every read call returns nil. I thought the select would fix
> that, but it returns immediately and the read call again returns nil.
>
> Am I misunderstanding how this should work? Would the fact that it's
> an SSL connection cause the issue?
>
> I'm using 1.8.4 on Linux.
>
> Thanks for any insights you can offer.
>
> Jeremy
I have an update to my initial question. I replaced my read calls with
sysread. With one client who sends to this server, the read or sysread
blocks as expected. With the other, the read always returns nil and
sysread always throws EOFError exceptions when I think it should
block. I catch EOFError and sysread again, but instead of blocking, it
throws EOFError again. And again. Etc.
Is this the correct behavior if they are keeping the client end of the
connection open (the working client -- the one where the read blocks
-- seems be keeping the connection open) or should the read be
blocking?
At this point, I'm beginning to think my only option will be to sleep
and then check the connection for data in a loop.
Jeremy