Designing socket messaging format
terabaap at yumpee.org
Tue Nov 13 07:31:50 CET 2001
Steve Holden wrote:
> "Manoj Plakal" <terabaap at yumpee.org> wrote in ...
>> This might cover a lot of cases where you don't
>> need RPC semantics (no return value expected)
> But some sort of response will usually be required, even if it's a simple
Sure, there will be situations where you
want an ACK, in which case you want
to do RPC. Or maybe you'd want an asynchronous
response instead of waiting for it. But
I believe there will be some cases where
you just want to send a notification and
not wait for anything.
>> and you're sending simple data values (so no
>> need of full-blown XML or other elaborate encoding).
> How simple is simple? ASCII strings of less than 256 characters you might
> get away with...\
I was thinking about fixing a grammar and
then having a parser for this grammar rather
than having a general XML parser and giving
it the DTD for the protocol.
>> And you may not even need a reliable transport
>> protocol (so no need of HTTP or even TCP).
>> XML-RPC is cool but it seems like a really
>> big and overweight hammer.
> Oh, so you don't mind if Word prints file "xyy.doc" when you ask it to print
By reliable, I meant stuff like acknowledgments
and sequencing and all that. I assume that
the data payload itself is protected from
corruption. Doesn't UDP have checksums?
> Can we say "UDP?
Sure you can use UDP, but I don't want
to use a separate application-level protocol
on top of UDP for each app I write or talk to.
I'm not trying to reinvent a new network
protocol here. All I'm asking is if there's
some kind of cross-platform ultra-lightweight
COM/CORBA-kind of messaging system, built on top
of some IPC mechanism (UDP or domain sockets or named
pipes or something not too heavy).
I did find a link to XPLC: xplc.sourceforge.net
More information about the Python-list