lists or dicts over zeromq in python

Encode as JSON before sending, and decode as JSON after receiving.

In zeroMQ, a message is simple a binary blob. You can put anything in it that you want. When you have an object that has multiple parts, you need to first serialize it into something that can be deserialized on the other end. The simplest way to do this is to use obj.repr() which produces a string that you can execute at the other end to recreate the object. But that is not the best way.

First of all, you should try to use a language independent format because sooner or later you will need to interact with applications written in other languages. A JSON object is a good choice for this because it is a single string that can be decoded by many languages. However, a JSON object might not be the most efficient representation if you are sending lots of messages across the network. Instead you might want to consider a format like MSGPACK or Protobufs.

If you need a topic identiffier for PUB_SUB, then simply tack it onto the beginning. Either use a fixed length topic, or place a delimiter between the topic and the real message.

JSON:

# Client
socket.send(json.dumps(message))

---

# Server
message = json.loads(socket.recv())

More info:

• JSON encoder and decoder
• hwserver.py
• hwclient.py

Manual serialization

You turn the data into a string, concatenate or else, do your stuff. It's fast and doesn't take much space but requires work and maintenance, and it's not flexible.

If another language wants to read the data, you need to code it again. No DRY.

Ok for very small data, but really the amount of work is usually not worth it unless you are looking for speed and memory effiency and that you can measure that your implementation is significantly better.

Pickle

Slow, but you can serialize complex objects, and even callable. It's powerfull, and it's so easy it's a no brainer.

On the other side it's possible to end up with something you can't pickle and break your code. Plus you can't share the data with any lib written in an other language.

Eventually, the format is not human readable (hard do debug) and quite verbose.

Very nice to share objects and tasks, not so nice for messages.

json

Reasonably fast, easy to implement with simple to averagely complex data structures. It's flexible, human readible and data can be shared accross languages easily.

For complex data, you'll have to write a bit of code.

Unless you have a very specific need, this is probably the best balance between features and complexity. Espacially since the last implementation in the Python lib is in C and speed is ok.

xml

Verbose, hard to create and a pain to maintain unless you got some heavy lib that that does all the job for you. Slow.

Unless it's a requirement, I would avoid it.

In the end

Now as usual, speed and space efficiency is relative, and you must first answer the questions:

• what efficiency do I need ?
• what am I ready to pay (money, time, energy) for that ?
• what solution fits in my current system ?

It's all what matters.

That wonderful moment of philosophy passed, use JSON.