You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Trustin Lee <tr...@gmail.com> on 2005/05/10 16:57:54 UTC
Re: ProtocolCodec question
Hi Emmanuel,
2005/5/9, Emmanuel Lécharny <el...@iktek.com>:
> Hi Trustin,
>
> real good job you did with MINA !
Thanks! :)
> I have a question about the ProtocolCodec stuff :
> - is it possible to have an encoder that can push chunks of PDU instead
> of pushing a whole PDU ?
You can push chunks of PDU by calling write(ByteBuffer) multiple
times. But MINA will flush the list of buffers you pushed in after
encode() method returns. So You'll be able to limit the maximum size
of ByteBuffer you allocate if you're using autoExpand mode, but MINA
doesn't flush them until encode() method returns. (WDYT about
autoExpand mode btw? ;)
<snip/>
> It may drive us to an architecture where MINA run on a dedicated JVM,
> and LDAP server running on another JVM, maybe on another server,
> communicates with MINA using sockets, for instance. (just an idea)
Sounds interesting. Any benefits here?
Thanks,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
Re: ProtocolCodec question
Posted by Emmanuel Lecharny <el...@apache.org>.
On Thu, 2005-05-12 at 09:28 +0200, Julien Vermillard wrote:
> Merci :)
>
> It's going to be helpfull.
>
> Julien
>
Bon courage, then !
Re: ProtocolCodec question
Posted by Julien Vermillard <jv...@archean.fr>.
Merci :)
It's going to be helpfull.
Julien
Le jeudi 12 mai 2005 à 02:05 +0200, Emmanuel Lecharny a écrit :
> Hi,
>
> assuming that you are the 'vrm' who asked 'know a good start point for
> learn ASN1 ?' on IRC, here are some pointers :
>
> A short introduction :
> http://luca.ntop.org/Teaching/Appunti/asn1.html
>
> If you want to know everything about ASN.1 :
> http://asn1.elibel.tm.fr/
>
> There is also a book you should read if you think that reading X.680,
> X.681, X.683 and X.690 is a kind of punishment :
> "ASN.1 : Communication entre Systèmes hétérogènes" de Olivier Dubuisson
> ISBN 2-287-59670-4
> SPRINGER, 65€
>
> (this is the french book, you could also download the translated version
> at http://www.oss.com/asn1/dubuisson.html. Olivier Dubuisson is working
> for FT R&D at Lannion, France)
>
> The book is really good.
>
> You have a subproject called ASN.1 where you have many interesting
> information (from which I have extracted some of the upper links) :
> http://directory.apache.org/subprojects/asn1/index.html
>
> You could also read the wiki pages, even if they are not very good or
> complete :
> http://wiki.apache.org/directory/Asn1Home
> http://wiki.apache.org/directory/TLVPageInfo
>
> The SPNEGO stuff could help you to understand how it works, as it is
> really close to the way it is coded in Sandbox, even if not perfect.
>
>
> If you need more specific informations, mail to the dev list (IRC is
> cool, but we are not always connected or able to reply... (damn
> firewall :)) !
>
> Emmanuel Lécharny
>
>
Re: ProtocolCodec question
Posted by Emmanuel Lecharny <el...@apache.org>.
Hi,
assuming that you are the 'vrm' who asked 'know a good start point for
learn ASN1 ?' on IRC, here are some pointers :
A short introduction :
http://luca.ntop.org/Teaching/Appunti/asn1.html
If you want to know everything about ASN.1 :
http://asn1.elibel.tm.fr/
There is also a book you should read if you think that reading X.680,
X.681, X.683 and X.690 is a kind of punishment :
"ASN.1 : Communication entre Systèmes hétérogènes" de Olivier Dubuisson
ISBN 2-287-59670-4
SPRINGER, 65€
(this is the french book, you could also download the translated version
at http://www.oss.com/asn1/dubuisson.html. Olivier Dubuisson is working
for FT R&D at Lannion, France)
The book is really good.
You have a subproject called ASN.1 where you have many interesting
information (from which I have extracted some of the upper links) :
http://directory.apache.org/subprojects/asn1/index.html
You could also read the wiki pages, even if they are not very good or
complete :
http://wiki.apache.org/directory/Asn1Home
http://wiki.apache.org/directory/TLVPageInfo
The SPNEGO stuff could help you to understand how it works, as it is
really close to the way it is coded in Sandbox, even if not perfect.
If you need more specific informations, mail to the dev list (IRC is
cool, but we are not always connected or able to reply... (damn
firewall :)) !
Emmanuel Lécharny
Re: ProtocolCodec question
Posted by Julien Vermillard <jv...@archean.fr>.
Le mardi 10 mai 2005 à 23:57 +0900, Trustin Lee a écrit :
> > It may drive us to an architecture where MINA run on a dedicated JVM,
> > and LDAP server running on another JVM, maybe on another server,
> > communicates with MINA using sockets, for instance. (just an idea)
>
> Sounds interesting. Any benefits here?
Perhaps running 2 VServer, with one for LDAP and one for MINA on the
same hardware
Julien
Re: ProtocolCodec question
Posted by Trustin Lee <tr...@gmail.com>.
Hi,
2005/5/11, Emmanuel Lecharny <el...@gmail.com>:
> > > I have a question about the ProtocolCodec stuff :
> > > - is it possible to have an encoder that can push chunks of PDU
> instead
> > > of pushing a whole PDU ?
> >
> > You can push chunks of PDU by calling write(ByteBuffer) multiple
> > times. But MINA will flush the list of buffers you pushed in after
> > encode() method returns.
>
> Isn't it possible that MINA flush the chunks before the encode method
> return ?
I can fix it to do so.
> > So You'll be able to limit the maximum size
> > of ByteBuffer you allocate if you're using autoExpand mode, but MINA
> > doesn't flush them until encode() method returns. (WDYT about
> > autoExpand mode btw? ;)
>
> It would be very coll if neither the encoder nor MINA creates a 10Mb
> ByteBuffer before sending it (think about a LdapSearch which returns all
> Ldap entries ...) In this case, the data will be store twice : once in
> the POJO and once in the ByteBuffer. not very good ...
You're right, but I think MiNA can force users to use smaller buffers.
But we'll have to write somewhere like FAQ about this issue.
> on a muli-processor computer, it will make a better usage of each
> processor... But I'm thinking of MINA as a front-end, like Apache is for
> J2EE servers. may be it's a little bit too early ?
>
> Another advantage would be that MINA could send DNS requests to a
> DNS/ApacheDS which run on a JVM, Kerberos requests to a
> Kerberos/ApacheDS server, Ldap requests to a Ldap/ApacheDS server,....
> If the Ldap server is down, you still have the DNS and Kerberos servers
> running. That means that maintenance operations are possible without
> stopping all the services. Of course, this is only possible if MINA is
> able to handle connexion on different ports (I don't know MINA enough to
> tell). MINA could then be a front-end that dispatch requests to the
> servers, so you don't have to launch an instance of MINA for each
> server. Does it make sense ?
Yes, it makes sense. But we'll have to consider the latency issues,
too, though latency becomes zero if we use VM pipe.
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/