From: Brian Candler <B.Candler@...>
Date: 2007-05-09T23:54:46+09:00
Subject: Re: NetworkFacade 0.4

On Wed, May 09, 2007 at 10:11:44PM +0900, Florent Solt wrote:
> > * Ability to pass Undumped objects in such a way that the callback
> > is either made back down the same socket, or to a global URI (the
> > latter is what DRb does). The latter also allows the callback to
> > be made independently, and avoids forming long chains of tunnels. (+)
> 
> I don't realy understand this point, my english is not perfect :)
> Could you explain it, thanks.

Firstly, do you understand DRbUndumped? It took me a while to work this out,
and I ended up writing it up on the web. See
http://wiki.rubygarden.org/Ruby/page/show/DRbTutorial
and see if that makes sense.

In particular, skip down to section headed "Why does the client run
'DRb.start_service'?"

> > * Basic protocol uses only string encoding, allowing tiny implementation
> > suitable for embedded devices etc, and cross-language interoperability.
> >
> > * Optionally enable other native marshalling protocols (e.g. Marshall, 
> > YAML, Perl Storable etc) if understood by both sides. Ideally negotiated.
> 
> I already thought about that, and I would like to release this in the 
> next
> version (0.5). I would like to have these serialization methods :
>   - YAML
>   - JSON
>   - XML
>   - Marshall-Ruby
> 
> And in a second time :
>   - PHP
>   - Perl
>   - String encoding
> 
> I already don't know some problem, for example, how to serialize a ruby
> exception in php format :)

As the lowest common denominator, I would encode an exception as a string.
It's pretty much impossible to map arbitary PHP exceptions to Ruby
exceptions and vice versa, so on receiving one of these exceptions you'd
create a generic exception, say NetworkFacade::RemoteError, with the message
containing the string.

Or maybe you could return an array of [class, message, backtrace].

If the two ends agree on Ruby Marshal, then the exception can be sent in
this format. You might still have to turn this into a generic RemoteError,
e.g. if the exception class contained in the marshalled object is not known
at the client side.

> > * Optional SASL authentication as well as, or instead of, SSL. This 
> > allows basic username/password authentication (AUTH PLAIN) which is
> > simpler to configure than client certificates.
> 
> It could be a great idea but I'm not familiar with SASL, I will take a 
> look
> at some docs.

RFC 2222 is the base SASL document, but it's not very helpful. A good
starting point is to see how CRAM-MD5 is done in IMAP (RFC 2195) and then
look at the PLAIN method (RFC 2595). This brings SASL back down to the level
of a simple username and password login :-)

It doesn't have to be SASL of course, but this is the official "extensible"
authentication mechanism for protocols. In the end, having a simple
username/password or shared secret authentication on top of TLS is what I'd
like to see.

> > I also think that implementations should consider using an opaque key to
> > identify each object, rather than it's object_id. For one thing, 
> > object_id's can be recycled; for another, it prevents people probing
> > for random objects which have not been explicitly shared. Keeping a
> > mapping table of opaque_key => object will prevent DRbUndumped objects
> > from being garbage collected (although this may or may not be desirable)
> 
> object_id is just used with the logger (through client_id method) to 
> print
> something revelant to the user, and for example, it's overloaded by
> TCP::Server. So, if I'm not wrong, it's not necessary.

Some sort of object_id is needed when making callbacks - but we are back to
the issue of DRbUndumped.

BTW I think if you're going to use your existing library as a starting point
and start modifying it, then you'll need at least a protocol version field
on connection :-)

I think many or all the options - SSL, Zlib, Marshal, Pipeline (overlapping
requests down the same socket) etc - could be offered as bits in a bitmap.
Some of them are conflicting, e.g. the server will not choose both SSL and
Zlib simultaneously.

Another thought: when using SSL, the client should negotiate SSL so that the
same port can be used for SSL and non-SSL connections. Also it should send
the hostname it connected to in the initial connection message, before SSL
is turned on. This enables 'virtual hosting' where the server can choose the
correct one out of many certificates. You might not think this is important,
but it's something which can easily be gotten right if you design it in at
the start.

RFC 2817 describes a HTTP extension for this. Unfortunately, because it came
along late, no-one implements it so we're stuck with having separate ports
for HTTP and HTTPS :-(

Regards,

Brian.