Re: [zeromq-dev] Memory pool for zmq_msg_t

2019-08-14 Thread Doron Somech
Jens I like the idea. We actually don't need the release method. The signature of the allocate should receive zmq_msg and allocate it. int ()(zmq_msg *msg, size_t size, void *obj); When the allocator will create the zmq_msg it will provide the release method to the zmq_msg in the constructor.

Re: [zeromq-dev] Memory pool for zmq_msg_t

2019-08-14 Thread Jens Auer
Hi, Maybe this can be combined with a request that I have seen a couple of times to be able to configure the allocator used in libzmq? I am thinking of something like struct zmq_allocator { void* obj; void* ()(size_t n, void* obj); void ()(void* ptr, void* obj); }; void*

Re: [zeromq-dev] Why UDP transport is just for radio/dish?

2019-08-14 Thread Doron Somech
It was easier to implement it to radio/dish than pub/sub. The reason is, multi-part messages would require a custom protocol on top of UDP to support the multi-part. Because UDP is not reliable that means encode all the parts into same UDP message. Because radio/dish is single frame, the

[zeromq-dev] Why UDP transport is just for radio/dish?

2019-08-14 Thread Francesco
Hi all, Out of curiosity I would like to test performances using UDP transport instead of TCP (my wild guess would be that zmq needs to do less framing/unframing work since UDP is already packet based)... But apparently push/pull sockets cannot use UDP transport...why? Thanks Francesco