Paul Rubin wrote:
Hmm, you also want a random blob in each packet (including the session start) included in the authentication of the next packet, so the attacker can't cut and paste messages from old sessions into the current ones. You know, by the time you're through designing this you may be better off just using SSL and getting it over with. It's very easy to make mistakes designing these types of protocols. There are some reasonable examples in "Applied Cryptography", but maybe you don't want to deal with this stuff.
Heh, indeed I rather don't. I know a bit about this stuff, but not nearly enough to come up with a water tight design by myself, so it's much easier and safer to rely on trusted work by others.
I label things like SOAP and XML-RPC much different than RMI or Pyro, because they (SOAP) are much more "distant" from the actual programming language and environment beneath them. I don't know if this is good thinking or not but the fact that RMI and Pyro expose language features directly, and SOAP not, makes that I reason about them differently.
Hmm, I sort of understand this, but not completely. Does DCOM or .NET expose language features directly?
.NET: no idea DCOM: as it is based on DCE/RPC, I would say: no. There's this MIDL thing sitting in between and stuff like that. There's no such thing as a specific class id and/or method name and/or parameter list that directly maps onto an object.method in the programming environment.
I must confess, this stuff is getting all rather messy and probably not worth to try to make such a distinction between all the RPC protocols :-)
I've been meaning to look at Pyro and will certainly let you know if I spot any problems, but of course there might be some that I don't find.
I would appreciate it.
Furthermore there are practical issues such as having to open a buch of new ports in your firewall. In my experience this is very hard to get done, sadly, in contrast to just exposing a "web-service" (in whatever form) on port 80 HTTP.
Yes, though RMI requires the same.
Precisely. There is this tunneling thing, but I never got it to work. In the end, using a SSH tunnel may prove to be even easier :-D (just let sshd listen on port 80 and you're set)
--Irmen
-- http://mail.python.org/mailman/listinfo/python-list
