From: Florent Solt Date: 2007-05-09T22:11:44+09:00 Subject: Re: NetworkFacade 0.4 Before anything else, thanks for your long and interesting reply. > I can't find any documentation of the TCP protocol itself. The documentation is still incomplete, I will wait some versions to improve it. > > Looking at the code, the call appears to be a four-byte length followed > by > a Marshal dump of > [@uri.path[1..-1], name, args] > and the response is a 4-byte length followed by a Marshal dump of a > single > object. This means that the protocol is similar to DRb, but different, > i.e. > not compatible :-( It's true. I don't try to do a compatible protocol, because I think it's difficult to add some new ideas with the same protocol. > > I can see a problem with this protocol: it's impossible to distinguish > between a method returning an Exception object and a method raising an > exception. Also true. I do not realize that. I will try to fix it. > There are certainly problems which DRb has which could do with solving. > Chief in my mind these are: > > (1) Doesn't run easily over FastCGI, IO.popen and stdin/stdout, or Unix > domain sockets. > > (2) Doesn't allow bi-directional method calls through a single > connection,e.g. for use through a firewall and/or NAT and port forwarding. > > (3) Doesn't interoperate with non-Ruby applications. I would like to be > able to carry strings and integers as plain strings. This would make it > easy to interoperate with Perl, say. > > (4) Not easy to secure. > > (5) Large and complex implementation, not easy to understand, especially > with regards to connection caching and what happens if connections are > dropped. > > Your library addresses (4), (5) and part of (1). But I think (2) and (3) > need careful thinking to produce a suitable protocol. As for (2), I'm > not sure your protocol supports proxy objects at all, a.k.a. > DRbUndumped, but please correct me if I'm wrong. > > I think a replacement protocol for DRb should have the following > characteristics: > > * 'Requests' and 'Responses' explicitly marked as such, so that calls > can be made in both directions down the same socket. I will do this, you are right. > * Each Request and Response to be tagged with an ID, so multiple > overlapping calls can be multiplexed onto the same socket, meaning > that only a single TCP connection needs to be kept open > between a particular pair of hosts. Very interesting too, I will implement this too. > * 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. > * 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 :) > * 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. > * Optional synchronous mode (one request -> one response) for tunneling > over HTTP or FastCGI and for simplistic implementations in embedded devices I will think about this too, I could be cool, but I don't know if I will be able to merge this with the current code. > * Automatic establishment or re-establishment of dropped connections Already planned :) > 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. > Just a few thoughts. Thanks again for your thoughts. > > Regards, > > Brian. > > (+) It would be useful to pass a different global URI depending on where > you are connecting to. For example, if you are connecting outbound through > the Internet, the global URI you expose may be your firewalls' outside IP or > hostname and a port on the firewall which forwards inbound connections. > > To make this more transparent, it could be useful to auto-detect NAT. > This could be done by passing your *actual* source IP and port inside the > connection message; the far end would compare these to the *seen* source > IP and port. IPSEC NAT traversal uses a similar mechanism. This could be great, but not for the moment. I will wait a stable and clean API before doing this kind of feature. Best regards. -- Posted via http://www.ruby-forum.com/.