[Date Prev][Date Next] [Chronological] [Thread] [Top]


bart@etpmod.phys.tue.nl wrote:
> On 14 Jun, Kurt D. Zeilenga wrote:
> > David Boreham wrote:
> >
> >> You'll probably find that you need some sort
> >> of unread operation too. I did for the server.
> >> Big PITA it is too.
> >
> > I'm thinking that this could be avoided by having a dataAvailable
> > hook...  but, yes, something is needed to manage issues concerning
> > low-level I/O availability and ber-level data availability.
> > That is, a socket can be selectable but no data is yet available
> > due data decryption requirements.
> Well, the situation where there is data available on the socket (socket
> is selectable), but this new data is held up by the crypto layer is not
> a big problem. The read operation could just return a EWOULDBLOCK type
> error. If I remember correctly, both libldap and the servers handled
> this okay.
> It gets more interesting when there is no data on the socket, but there
> is data available from the crypto layer. For this situation, it will be
> necessary to modify all calls to 'select'.

Hit me with a mallet, please.   How is this possible?

As long as the caller drains the connection to EWOULDBLOCK, than the crypto
layer has given up all data that ready for the caller.... and data that's
not ready needs more from the wire.

The server clearly does this....  is this a -lldap issue?