directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Trustin Lee <>
Subject Re: kerberos seda question
Date Fri, 24 Dec 2004 04:59:47 GMT
Now I got it.  I just thought the four bytes prefix were unexpected
stuff.  My misunderstandings.

You'll have to write a separate Decoder for TCP transport.  TCP and
UDP is different because there is no guarentee one message comes as a
single packet in TCP.  You'll have to file all bytes until one message
is fully read.

Trustin Lee

On Thu, 23 Dec 2004 20:22:51 -0500, Enrique Rodriguez
<> wrote:
> 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
> >>snickers.
> >
> > 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,
> "draft-ietf-krb-wg-kerberos-clarifications-07.txt":
> "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.
> -enrique

what we call human nature is actually human habit

View raw message