directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu (JIRA)" <>
Subject [jira] Commented: (DIREVE-87) PDU sizes above 255 make JNDI clients hang
Date Sat, 27 Nov 2004 03:40:19 GMT
     [ ]
Alex Karasulu commented on DIREVE-87:

Well I think I figured out this son of a bitch!  Looks like we're not handling the long length
form correctly when more than one byte is used.  That's why we hit a wall above 256 bytes.
 The anomoly at 257 was explained by this too however I will not go into its details.  It
was just luck that 257 worked.  

Basically changes need to be made to the low level BER codec.  I will make those changes now.

> PDU sizes above 255 make JNDI clients hang
> ------------------------------------------
>          Key: DIREVE-87
>          URL:
>      Project: Directory Eve
>         Type: Bug
>   Components: protocol
>     Reporter: Alex Karasulu
>     Assignee: Alex Karasulu
>     Priority: Blocker

> Oh I've been wrestling with this bug for some time now and thought it might be a good
idea to get a JIRA out on it.  This bug is basically in my way preventing me from really rapidly
finishing off the rest of the protocol provider that plugs into SEDA.  Here's a characterization
of the bug and how to reproduce it:
> When the top level TLV tuple of an LDAP response message is 255 or smaller there is no
problem at all with transmission.  However when it is 256 bytes then transmission occurs without
reciept of attributes by SUN JNDI LDAP clients but nothing blocks.  At 257 bytes the transimission
is excellent with complete reciept of all attributes and no blocking.  At 258 bytes and above
all clients fail on receipt of the transmission and hang.  Here's a synopsis:
> --> PDU's <= 255 bytes all is well
> --> PDU's == 256 bytes we loose attributes but client does not hang
> --> PDU's == 257 bytes all is well
> --> PDU's >= 258 bytes we get nothing back and client hangs
> I basically verified that the generated PDU by the server is being delivered correctly
to the client and that the client is recieving the PDU as it was transmitted.  I confirmed
all this using debugging on Eve, the client, and using Ethereal dumps of TCP streams.  So
this leads me to one conclusion at this point:
> We are not generating the correct ASN.1 BER encoding for PDU's bigger than 255 bytes.
 We're getting lucky on transmissions at 256, and 257 bytes.   Anything larger than this is
interfering with the interpretation of the following search response done PDU that comes right
after the malformed search entry result PDU.  Hence this is what is causing the client to
hang thinking the search has not completed yet.  
> I guess I got to get back into the ASN.1 stuff to fix this.  Stay tuned to this bat channel
for more updates to follow ...

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
If you want more information on JIRA, or have a bug to report see:

View raw message