[jira] Commented: (DIREVE-87) PDU sizes above 255 make JNDI clients hang

["Alex Karasulu (JIRA)" <di...@incubator.apache.org>]

     [ http://nagoya.apache.org/jira/browse/DIREVE-87?page=comments#action_55901 ]
     
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: http://nagoya.apache.org/jira/browse/DIREVE-87
>      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:
   http://nagoya.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira