David, thanks for your response, it's great when people take the time to read a lengthy question and then respond with some insight! David Ripton wrote:
PB allows both ends of the connection to send and receive at any time, over a single connection. I use it for a game where multiple clients connect via TCP to a server, and then the clients send messages to the server whenever they want, and the server sends messages to one or more clients whenever it wants (over the original connections initiated by the clients, so the clients don't need to open any holes in their firewalls), and everything just stinking works.
I ended up sort of answering this one for myself by just playing with a basic chat server example and sniffing packets - only saw SYN,SYN-ACK,ACK once for each client. Though it would be nice if the documentation gave this level of detail, presumably this is something that belongs with the different transports.
That's not the way XML-RPC is typically done. Clearly you could make a protocol that uses XML-RPC payload over a persistent connection. But you'd lose the ability to use arbitrary XML-RPC libraries unmodified, which is probably the main benefit of choosing XML-RPC.
Duh, good point! Guess I was kinda trying to map our requirements onto an example that looked easy (from the book).
If not for the Java requirement, I would say that Twisted is a good fit, and that you could use either PB or AMP, depending on whether you want to pass around complex types or simple ones. But if you need Java, I don't know.
Guess I'll have to take a closer look at the Java implementation. Not sure why I didn't stumble across AMP before but looks promising... Thanks, -Blair -- In science one tries to tell people, in such a way as to be understood by everyone, something that no one ever knew before. But in poetry, it's the exact opposite. - Paul Dirac