orivej / pzmq

ZeroMQ 4.0+ Common Lisp bindings.

Home Page:http://orivej.github.io/pzmq/doc/index.html

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

SETSOCKOPT :IDENTITY does not accept binary data

phoe opened this issue · comments

(let ((identity (concatenate '(vector (unsigned-byte 8))
                             (babel:string-to-octets "Gateway Client")
                             '(0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0)
                             (ironclad:random-data 32))))
  (pzmq:setsockopt socket :identity identity))

I would expect this to work, but the :identity socket option seems to only accept strings. This is contrary to the description of zmq_setsockopt(3), which says:

The ZMQ_IDENTITY option shall set the identity of the specified socket when connecting to a ROUTER socket. The identity should be from 1 to 255 bytes long and may contain any values.

This includes values that are likely to be invalid as a string, e.g. an identity containing null bytes. For this, I would expect to be able to pass an ub8 vector there.

This should have worked according to CFFI example. Could you find a fix for this and apply it here? (If you do, please also check if getsockopt :identity has a reasonable behavior.)

This is a CFFI bug. The example they have doesn't compile:

(let ((array (coerce #(84 117 114 97 110 103 97)
                     '(vector (unsigned-byte 8)))))
  (with-foreign-string (foreign-string array)
    (foreign-string-to-lisp foreign-string)))

I have opened a ticket at https://bugs.launchpad.net/cffi/+bug/1865442 and will want to keep this one open for tracking purposes.

Thank you! I have subscribed to your bug report. It is not obvious in which way it will be resolved, since unlike the example the documentation says that the argument should be a Lisp string. (I would certainly prefer if it also allows ub8 vectors.) Regardless, I would accept a workaround in pzmq.

The function docstring and offline documentation contradict each other. I will wait for CFFI maintainers to resolve that one first and foremost; we'll adapt according to what they do.

(For now, I'll use string identities.)