Mailing-List: contact directory-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List"
 <directory-dev@incubator.apache.org>
Received-SPF: pass (hermes.apache.org: domain of trustin@gmail.com designates
 64.233.184.194 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references;
        b=fVJuqz5LKqxi3F079y3WRVfWAvZPFFtT5CZh4XvRHmHGwu8yKu6D79l3RkGdd3rxgdoLkQ3EGb0Y5a99qWwen0GLbJraroUtQSc8WQlZ8XrO/j52LvK9Gm6GXw508zZUksYp+uqaFOfMf5ENDa69d1mKrcNvmRQElvrpQGpLacc=
Message-ID: <768dcb2e04122320591a065992@mail.gmail.com>
Date: Fri, 24 Dec 2004 13:59:47 +0900
From: Trustin Lee <trustin@gmail.com>
Reply-To: Trustin Lee <trustin@gmail.com>
To: Apache Directory Developers List <directory-dev@incubator.apache.org>
Subject: Re: kerberos seda question
In-Reply-To: <41CB6F6B.1080705@apache.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <41C9318C.1020008@apache.org>
	 <768dcb2e04122315376bc6678@mail.gmail.com>
	 <41CB6F6B.1080705@apache.org>

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.

Cheers,
Trustin Lee

On Thu, 23 Dec 2004 20:22:51 -0500, Enrique Rodriguez
<erodriguez@apache.org> 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
--
http://gleamynode.net/