[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Let's make Lua mobile!
- From: David Hollander <dhllndr@...>
- Date: Sat, 29 Oct 2011 21:30:42 -0500
Let me proposes a different protocol that might suit your needs:
1st and 2 byte: message length
X bytes: message
message = any serialized lua value.
Pass (senderIP, message) to a handler. The end :)
- David Hollander
On Thu, Oct 27, 2011 at 3:28 PM, Ezra Sims <firstname.lastname@example.org> wrote:
> On 10/27/2011 11:35 AM, Stefan Reich wrote:
>> Hi Ezra!
>> Thanks for your answer!
>> Would XMPP work for sending a frozen script (just a binary image)
>> between different machines?
> Yep. Jingle  (which most clients and libs support) allows for file
> transfer, or for small amounts of data you could just compress, hex-encode,
> and send the image as a standard message with an identifying prefix for the
> receiver to parse. I'm sure there are plenty of other methods supported by
> the protocol, those are just the two that happen to come to mind first.
>> If yes, do you have code to do this? I
>> really want to just start doing it (sending a few scripts around the
> Not at the moment, but I doubt it would take long to come up with something
> workable. I'd start with Verse  (I have ready-made squishes and
> test/example code if you have trouble getting it working from the repo) and
> figure out what works from there.
>> My own first idea was to use zmq for communication. But I haven't
>> really started exploring it it yet, just informed myself about it a
>> little. If XMPP provides useful, let's go for XMPP.
> It depends completely on implementation. I probably know even less about zmq
> than you, but I do know it'll very likely be faster than XMPP if distributed
> computing is involved. XMPP does have the huge advantage of being a chat
> protocol, which makes client discovery and non-binary communication (state
> and overload notifications, handshakes, etc) trivial to implement.
> For a lib I'd leave the connection up to the application, defining pluggable
> methods for I/O. At an application level, if I had to pick only one my first
> choice would be XMPP - it takes a *lot* of fairly complex work out of the
> picture. Set up a server, figure out a way to handle registration on the
> client level, call it good.
> If speed becomes an issue under an XMPP implementation with no XEP to handle
> things better, perhaps a hybrid approach using XMPP for basic communication
> while ZMQ handles the 'dirty work' of sending and receiving data would work
> There's all sorts of ways, and I'd be happy to collaborate if you'd like.
> Feel free to contact me directly.
>  http://xmpp.org/extensions/xep-0234.html
>  http://code.matthewwild.co.uk/verse