directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Enrique Rodriguez <>
Subject Re: kerberos seda question
Date Fri, 24 Dec 2004 01:22:51 GMT
Trustin Lee wrote:
> Hi,
>>TCP still doesn't work, though the fix is pretty straightforward, but I
>>a have a question about the best way to implement it.  TCP payloads are
>>prepended with the 4-byte total length of the PDU.  This isn't on the
>>UDP payload, so it goes through snickers just fine.  It is there in TCP,
>>but I don't really care about it, and the result is decoding breaks in
> It is really strange.  SEDA doesn't prepend the length of PDU.  At
> least one module must be adding it.  I think Alex could help us here.

This is a normal addition to TCP versions of protocols.  The following 
is from the kerberos draft pertaining to TCP, 

"Each request (KRB_KDC_REQ) and response (KRB_KDC_REP or KRB_ERROR) sent 
over the TCP stream is preceded by the length of the request as 4 octets 
in network byte order."

With Netty2 I would strip this off requests and add it to responses. 
But, as Netty2 was TCP-only, I could assume the presence of these octets.

>>(a) where should I strip that value prior to decoding?  Is it really the
>>responsibility of a protocol implementor?  What is the LDAP protocol
>>doing (I'll look tomorrow aka later today)?
> You could strip that four bytes in KerberosDecoder before passing the
> bytebuffer to TupleTreeDecoder.

Yes, as this is part of the Kerberos draft and not specific to TCP, this 
is the responsibility of the Kerberos codecs.

>>(b) how can I tell whether to strip?  Is there a way to tell if a BB
>>came in on TCP vs UDP?
> There is not way to distinguish them.  You'll have to compare the
> stripped and unstripped version.  It might be not so easy to do, so
> we'd better find who is adding that 4 bytes header.

I know I've seen this in other protocols, so it might be nice to have a 
more explicit way for protocol implementors to tell whether a request 
came in on TCP vs. UDP.  Perhaps in the ClientKey?

Further, we will have to maintain the knowledge that the request was TCP 
vs. UDP, as the response must be returned using the same transport as 
the request:

"The response to a request made through UDP/IP transport MUST also use 
UDP/IP transport."

... and:

"When the KRB_KDC_REQ message is sent to the KDC over a TCP stream, the 
response (KRB_KDC_REP or KRB_ERROR message) MUST be returned to the 
client on the same TCP stream that was established for the request."

Since the first octets are going to be the length or a Kerberos message 
type, I can use conditionals, but I would prefer to perform a more 
explicit check.


View raw message