[openstack-dev] [oslo] rpc envelope (was: blueprint amqp-rpc-fast-reply-queue)

Eric Windisch eric at cloudscaling.com
Wed Jan 30 15:48:08 UTC 2013

On Tuesday, January 29, 2013 at 11:35 AM, Eric Windisch wrote:
> > 
> > Russell did originally add a config option to allow enabling the new
> > format, but I said:
> > 
> > Why would a user choose to enable the new format now? Isn't there
> > basically no benefit until we start using the new format to do
> > something interesting in H?
> Perhaps my concern come late, but I do have an outstanding question if the new envelope format is really a good thing, as presently designed.
> Message signing requires that the signed message is a string including at least some bits being serialized. That message will need to include the actual message_data, but also the topic, a timestamp, ttl, etc. These are pieces that will need to become part of the envelope. They need to be either serialized along with the message data or concatenated with the message data to be signed. Serializing these pieces together seems far more optimal. However, keep in mind that the message signature chain will need to be separate.
> Furthermore, the code currently double-serializes all the content. Kombu serializes data with JSON transparently, unless told otherwise, and the same is done with ZeroMQ. At least with ZeroMQ, if the array is convertable via bytes(), then we can send it without the double serialization, but the envelope is currently a dict, so the double-serialization is still required... I'm not so certain if we can avoid it for Kombu, but I do know the default JSON serialization can be disabled.
> Additionally, unless the envelope is an array that can be converted to bytes(), the ZeroMQ driver will continue to require a driver-specific envelope around the generic RPC envelope for purposes of performance.

Upon further consideration, if the ZeroMQ driver will need to do its own serialization/deserialization anyway, then one viable option as part of that effort is to flatten the RPC envelope into an array (assuming it remains a dict). There could be issues if any values are introduced that are not byte() compatible, such as lists or dictionaries. However, this would avoid the ZeroMQ driver needing a separate envelope or doing a second json.dumps()/loads(), as the array zipping would be sufficient.  Performance wise, flattening and recombining an array is significantly faster than serializing/deserializing JSON.

This seems a legitimate (ab)use since the rpc drivers are left to do their own serialization/deserialization and they all do it at present, albeit to JSON.

This would be done with something like (pseudo-code):

""" Sender """
rpc_envelope = rpc_common.serialize_msg(orig_msg)

zmq_msg = reduce(lambda x,y: x + y, zip(rpc_envelope.keys(), map(bytes, rpc_envelope.values()))

""" Receiver """
zmq_msg = zmq.recv()
rpc_envelope = zip([ zmq_msg[z] for z in range(len(zmq_msg)) if z % 2 == 0 ],
                   [ zmq_msg[z] for z in range(len(zmq_msg)) if z % 2 == 1 ])
orig_msg = rpc_common.deserialize_msg(rpc_envelope)

Eric Windisch

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130130/56ba9501/attachment.html>

More information about the OpenStack-dev mailing list