Re: [zeromq-dev] [Development] Linux: Qt support with ZeroMQ..
On 27 January 2014 15:11, Rahul Mathur sriv...@gmail.com wrote: I am newbie and looking for Qt support with ZeroMQ on Linux for desktop application. Can I have some links to perform below - 1. Qt bindings support to ZeroMQ 2. Installation 3. Executing ZeroMQ PUB-SUB with Qt enabled user inputs on it's GUI. I do have zermqt-master.zip file but it has missing README or INSTALLATION steps to execute Qt enabled zeromq. Thanks Hi, You'll probably have better luck asking the author of the plugin (https://github.com/wttw/zeromqt); this is not related to Qt itself. Note that Zeromqt is stated to be a pre-alpha product. You might also be interested in https://github.com/jonnydee/nzmqt Regards, Sze-Howe ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] Associating messages to authenticated clients
On Tue, Jan 21, 2014 at 07:04:07AM -0600, Pieter Hintjens wrote: On Tue, Jan 21, 2014 at 5:17 AM, Goswin von Brederlow goswin-...@web.de wrote: I played around with that and you can test it: https://github.com/mrvn/libzmq/tree/mrvn So far the code compiles (for me). I haven't had time to write a proper test case for it yet. But I've modifed tests/test_security_curve.cpp to call zmq_msg_get_user_id() and that seems to work: Awesome... could you push this as a pull request so we can play with it. Please check https://github.com/zeromq/libzmq/issues/802 where we were discussing this. I'd like to be able to access all sender metadata for a message, eventually, and allow clients to set metadata before connecting. Breaking the zmq_msg_t structure is problematic, it means recompiling applications as the size is defined in zmq.h. Perhaps we could add a new type, zmq_frame_t, for this, and take the opportunity to fix that msg/frame fuzziness. -Pieter This is just a first try and not ready to be merged. There are still several unresolved issues, like: 1) ABI breakage. I added the mechanism pointer to the message itself increasing its size and breaking ABI. That is a big problem. There are, so far, 2 possible solutions to this: a) only messages with contents need the pointer so the pointer could be moved into the union next to the content pointer. Afaik there is enough space there for it so the message structure doesn't have to grow. b) replace the FD field with a pointer to the socket base. The socket base then has the FD and a pointer to the mechanism so both can be accessed. What do you think? Does it make more sense to store the socket base? 2) memory management I beliefe the mechanism structure is destroyed when a peer disconnects. This would cause an unaceptable race condition with retrieving the user_id or credentials from a message. The mechanism pointer could become invalid at any point. I think the mechanism structure must be extended to have a reference count. Every message has to increment the count when the mechanism pointer is stored and decrement it when the message is closed or the pointer is otherwise reset. Similar for any other holder of a pointer to the mechanism, which would be the socket base, right? A mechanism structure would free itself when the count reaches 0. Note: When storing socket base pointers (1b) that would need reference counting. 3) API to access metadata, properties, ... I'm not sure how metadata and properties are suposed to be set and used. Should each have their own retrieval function? Or is one generic function similar to getsockopt enough? Maybe user_id and metadata should even just be another property? I just added zmq_msg_get_user_id() as a proof-of-concept. Seemed to be the simplest thing to test the idea. 4) write access to the metadata The user_id, metadata and properties can be set in the ZAP handler. But should that be the only palce they can be set? Maybe the application will want to set additional state or modify the data. Or is that infeasable because the data would silently get lost on reconnect? MfG Goswin ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] Linux: Qt support with ZeroMQ..
On Sun, Jan 26, 2014 at 11:34:13PM -0800, Justin Karneges wrote: There are a few options: https://github.com/wttw/zeromqt https://github.com/jonnydee/nzmqt https://github.com/jkarneges/qzmq It sounds like you've downloaded zeromqt. The project should contain README.markdown. I am the author of QZmq and can help with it if you'd like. On 01/26/2014 11:11 PM, Rahul Mathur wrote: I am newbie and looking for Qt support with ZeroMQ on Linux for desktop application. Can I have some links to perform below - 1. Qt bindings support to ZeroMQ 2. Installation 3. Executing ZeroMQ PUB-SUB with Qt enabled user inputs on it's GUI. I do have zermqt-master.zip file but it has missing README or INSTALLATION steps to execute Qt enabled zeromq. Thanks Can you give a few words of what makes each of them good or bad please? Why did you start your own project instead of using on of the other two? MfG Goswin ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] Associating messages to authenticated clients
On Mon, Jan 27, 2014 at 5:33 AM, Goswin von Brederlow goswin-...@web.de wrote: I added the mechanism pointer to the message itself increasing its size and breaking ABI. That is a big problem. a) only messages with contents need the pointer so the pointer could be moved into the union next to the content pointer. Currently small messages would use the VSM structure. You could force all messages into contents, if there is metadata. Or, if you used a separate method for receiving such messages. 2) memory management I think the mechanism structure must be extended to have a reference count. Sounds right. 3) API to access metadata, properties, ... I'm not sure how metadata and properties are suposed to be set and used. Should each have their own retrieval function? Or is one generic function similar to getsockopt enough? Maybe user_id and metadata should even just be another property? I just added zmq_msg_get_user_id() as a proof-of-concept. Seemed to be the simplest thing to test the idea. There are a set of fixed properties that are easiest to access via individual methods. And there is generic metadata that we'd access using a single get method. 4) write access to the metadata Unless you have a specific problem where modifying metadata in the application is the simplest solution, I'd stay away from this. It sounds like a bad idea anyhow. -Pieter ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] Associating messages to authenticated clients
On Mon, Jan 27, 2014 at 07:54:24AM -0600, Pieter Hintjens wrote: On Mon, Jan 27, 2014 at 5:33 AM, Goswin von Brederlow goswin-...@web.de wrote: I added the mechanism pointer to the message itself increasing its size and breaking ABI. That is a big problem. a) only messages with contents need the pointer so the pointer could be moved into the union next to the content pointer. Currently small messages would use the VSM structure. You could force all messages into contents, if there is metadata. Or, if you used a separate method for receiving such messages. Or make small 4/8 byte smaller and put the pointer at the end of the VSM structure. Messages would then switch to contents 4/8 byte earlier but the API wouldn't change since the message type is abstract to the application. 2) memory management I think the mechanism structure must be extended to have a reference count. Sounds right. 3) API to access metadata, properties, ... I'm not sure how metadata and properties are suposed to be set and used. Should each have their own retrieval function? Or is one generic function similar to getsockopt enough? Maybe user_id and metadata should even just be another property? I just added zmq_msg_get_user_id() as a proof-of-concept. Seemed to be the simplest thing to test the idea. There are a set of fixed properties that are easiest to access via individual methods. And there is generic metadata that we'd access using a single get method. 4) write access to the metadata Unless you have a specific problem where modifying metadata in the application is the simplest solution, I'd stay away from this. It sounds like a bad idea anyhow. -Pieter Ok. I will put that on my ToDo then. But I won't have time to work on this in the next 2 weeks or so as other matters are more pressing. If anyone wants to work a bit on this then feel free to send me a pull request. Or send one to the main repository if you finish the feature. MfG Goswin PS: don't forget test cases for all socket types and security mechanisms. ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] trying to understand zeromq high water mark behaviour
On Mon, Jan 27, 2014 at 07:15:03AM -0600, Pieter Hintjens wrote: Hi, The dealer socket distributes messages equally to all its peers, and the HWM isn't relevant here. Even busy workers will receive messages. You want some form of load balancing. The Guide has examples of this (load balancing brokers). -Pieter Is it completly irelevant? I naively thought the dealer would send equally to all sockets untill they block. And on the other side the socket would read ahead until its recv HWM is met. So at least recv HWM messages get queued up and then whatever fits into the send and recv buffers the kernel has for the sockets and whatever remains of the last message is buffered in zmq internally. Or is that completly wrong? MfG Goswin ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] trying to understand zeromq high water mark behaviour
It's not irrelevant but first, it defaults to 1000 and secondly there are buffers both at the sender and the receiver, as well as in TCP. On Jan 27, 2014 4:37 PM, Goswin von Brederlow goswin-...@web.de wrote: On Mon, Jan 27, 2014 at 07:15:03AM -0600, Pieter Hintjens wrote: Hi, The dealer socket distributes messages equally to all its peers, and the HWM isn't relevant here. Even busy workers will receive messages. You want some form of load balancing. The Guide has examples of this (load balancing brokers). -Pieter Is it completly irelevant? I naively thought the dealer would send equally to all sockets untill they block. And on the other side the socket would read ahead until its recv HWM is met. So at least recv HWM messages get queued up and then whatever fits into the send and recv buffers the kernel has for the sockets and whatever remains of the last message is buffered in zmq internally. Or is that completly wrong? MfG Goswin ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] Linux: Qt support with ZeroMQ..
Hi Goswin, On 01/27/2014 03:46 AM, Goswin von Brederlow wrote: On Sun, Jan 26, 2014 at 11:34:13PM -0800, Justin Karneges wrote: There are a few options: https://github.com/wttw/zeromqt https://github.com/jonnydee/nzmqt https://github.com/jkarneges/qzmq It sounds like you've downloaded zeromqt. The project should contain README.markdown. I am the author of QZmq and can help with it if you'd like. Can you give a few words of what makes each of them good or bad please? Why did you start your own project instead of using on of the other two? It's been a year and a half since I created QZmq, so I cannot remember the exact reason, but I believe it was because neither Zeromqt nor Nzmqt supported fully event-driven reads and writes (at least at the time), and I didn't agree with the headers-only style of development used by Nzmqt so I thought I'd try my own rather than contribute. So the advantage of QZmq is it supports write notifications, and it also includes a Valve class which makes it easy to implement backpressure. Probably one should choose between Nzmqt or QZmq. I believe Zeromqt has gone unmaintained, and its own documentation suggests uses Nzmqt instead. Justin ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] trying to understand zeromq high water mark behaviour
Thanks Pieter, I had another look at the output, and it does look like maybe the TCP buffer is involved somehow, the messages received by the slow worker were all from the beginning of the test sequence, so presumably they were sent out before the sockets started blocking due to HWM. Shaobo On 27 January 2014 16:01, Pieter Hintjens piet...@gmail.com wrote: It's not irrelevant but first, it defaults to 1000 and secondly there are buffers both at the sender and the receiver, as well as in TCP. On Jan 27, 2014 4:37 PM, Goswin von Brederlow goswin-...@web.de wrote: On Mon, Jan 27, 2014 at 07:15:03AM -0600, Pieter Hintjens wrote: Hi, The dealer socket distributes messages equally to all its peers, and the HWM isn't relevant here. Even busy workers will receive messages. You want some form of load balancing. The Guide has examples of this (load balancing brokers). -Pieter Is it completly irelevant? I naively thought the dealer would send equally to all sockets untill they block. And on the other side the socket would read ahead until its recv HWM is met. So at least recv HWM messages get queued up and then whatever fits into the send and recv buffers the kernel has for the sockets and whatever remains of the last message is buffered in zmq internally. Or is that completly wrong? MfG Goswin ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] TPubSub pattern
Hi Doron.,
Token-based pub-sub sounds interesting. I'm not sure how this fits
into what we're already doing with authentication. There's a
zeromq-dev thread on providing authentication credentials to the
caller per message.
-Pieter
On Sat, Jan 25, 2014 at 6:52 AM, Doron Somech somdo...@gmail.com wrote:
Hi All,
I created a new pattern in NetMQ which I think will also benefit ZeroMQ, the
pattern called TPubSub, the T is for Token, anyway if you have a better name
please do suggest.
The idea is to create a pubsub where the publisher decide on the subscriber
subscriptions, this is to achieve permission based subscriptions.
Instead of subscriptions the subscriber will send the publisher a token, the
publisher upon receiving the token will decide on the subscriber
subscriptions.
The token can be an x509 certificate or blob received by authorizing with
another service (can be a simple web service) and receiving an signed blob
with the client identity and maybe client permissions.
The publisher receiving the blob will be able to make sure it's authentic
and to set the client permission according to the permissions.
The TSub can set a token which will be send to any TPub the TSub is
connected to using zmq_setsockopt with option ZMQ_TSUB_TOKEN or send a
message prefixed with zero.
The TPub will receive any messages send by the TSub, the first frame will be
the identity (as in router) and then the message send by the TSub, the TPub
can set TSub subscriptions with first call to zmq_setsockopt with
ZMQ_TPUB_SELECT and the peer identity and then call zmq_setsockopt with
ZMQ_TPUB_SUBSCRIBE or ZMQ_TPUB_UNSUBSCRIBE along with the subscription.
You can take a look at the branch here:
https://github.com/somdoron/netmq/tree/fpubsub
Most of the magic happen at the TPub and TSub you can also take a look at
the unit testing to see how to use it:
https://github.com/somdoron/netmq/blob/fpubsub/src/NetMQ.Tests/TPubSubTests.cs.
I will add a pull request to NetMQ soon, I need to add some more testing and
want to hear your thoughts.
Also together with ZMTP 3.0 hopefully coming to all zeromq libraries we can
really have a secure pubsub.
Small example in C#:
using(NetMQContext context = NetMQContext.Create())
{
using (TPublisherSocket publisherSocket =
context.CreateTPublisherSocket())
{
publisherSocket.Bind(tcp://127.0.0.1:5557);
using (TSubscriberSocket subscriberSocket =
context.CreateTSubscriberSocket())
{
subscriberSocket.SetToken(all);
subscriberSocket.Connect(tcp://127.0.0.1:5557);
// first is the identity
byte[] identity = publisherSocket.Receive();
// now is the token, token always start with zero
byte[] token = publisherSocket.Receive();
Debug.Assert(token[0] == 0);
string tokenString = Encoding.ASCII.GetString(token, 1,
token.Length - 1);
if (tokenString == all)
{
publisherSocket.SelectPeer(identity);
// The peer will be subscribed to all messages
publisherSocket.SubscribePeer();
}
publisherSocket.Send(Hello);
string messsage = subscriberSocket.ReceiveString();
Debug.Assert(Hello == messsage);
}
}
}
Regards,
Doron
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] Linux: Qt support with ZeroMQ..
Question: One of the drawbacks of QT's signals and slots mechanism (which is otherwise great) is that it supports many-to-one (like ZMQ pull or sub) and one-to-many (like ZMQ pub), but it does't support one-to-any (like ZMQ push). Is there anything in any of these projects that addresses this in any way by merging the QT and ZMQ functionality somehow? On Mon, Jan 27, 2014 at 2:00 PM, Justin Karneges jus...@affinix.com wrote: Hi Goswin, On 01/27/2014 03:46 AM, Goswin von Brederlow wrote: On Sun, Jan 26, 2014 at 11:34:13PM -0800, Justin Karneges wrote: There are a few options: https://github.com/wttw/zeromqt https://github.com/jonnydee/nzmqt https://github.com/jkarneges/qzmq It sounds like you've downloaded zeromqt. The project should contain README.markdown. I am the author of QZmq and can help with it if you'd like. Can you give a few words of what makes each of them good or bad please? Why did you start your own project instead of using on of the other two? It's been a year and a half since I created QZmq, so I cannot remember the exact reason, but I believe it was because neither Zeromqt nor Nzmqt supported fully event-driven reads and writes (at least at the time), and I didn't agree with the headers-only style of development used by Nzmqt so I thought I'd try my own rather than contribute. So the advantage of QZmq is it supports write notifications, and it also includes a Valve class which makes it easy to implement backpressure. Probably one should choose between Nzmqt or QZmq. I believe Zeromqt has gone unmaintained, and its own documentation suggests uses Nzmqt instead. Justin ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] Linux: Qt support with ZeroMQ..
Mapping ZeroMQ sockets to Qt signals/slots would be wild. :) None of the existing libs attempt anything like this. I'd have to think more about the use cases. On 01/27/2014 01:39 PM, Lindley French wrote: Question: One of the drawbacks of QT's signals and slots mechanism (which is otherwise great) is that it supports many-to-one (like ZMQ pull or sub) and one-to-many (like ZMQ pub), but it does't support one-to-any (like ZMQ push). Is there anything in any of these projects that addresses this in any way by merging the QT and ZMQ functionality somehow? On Mon, Jan 27, 2014 at 2:00 PM, Justin Karneges jus...@affinix.com mailto:jus...@affinix.com wrote: Hi Goswin, On 01/27/2014 03:46 AM, Goswin von Brederlow wrote: On Sun, Jan 26, 2014 at 11:34:13PM -0800, Justin Karneges wrote: There are a few options: https://github.com/wttw/zeromqt https://github.com/jonnydee/nzmqt https://github.com/jkarneges/qzmq It sounds like you've downloaded zeromqt. The project should contain README.markdown. I am the author of QZmq and can help with it if you'd like. Can you give a few words of what makes each of them good or bad please? Why did you start your own project instead of using on of the other two? It's been a year and a half since I created QZmq, so I cannot remember the exact reason, but I believe it was because neither Zeromqt nor Nzmqt supported fully event-driven reads and writes (at least at the time), and I didn't agree with the headers-only style of development used by Nzmqt so I thought I'd try my own rather than contribute. So the advantage of QZmq is it supports write notifications, and it also includes a Valve class which makes it easy to implement backpressure. Probably one should choose between Nzmqt or QZmq. I believe Zeromqt has gone unmaintained, and its own documentation suggests uses Nzmqt instead. Justin ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org mailto:zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] Linux: Qt support with ZeroMQ..
The main use case from my point of view would be getting the benefits of ZMQ inproc messaging patterns coupled with the expected C++ object semantics provided by QT signals. The ability to give thread affinity to a QObject, effectively making any slot on that object be called in the same thread no matter where it was signaled, is phenomenally powerful. However, signals always go to all slots, so you can't do things like PUSH. On the other hand, inproc is also a very powerful interthread communication mechanism, but the need to serialize data to use it is a problem. You can send pointers around, of course, but then the problem becomes maintaining ownership semantics properly. So we have the power of patterns on the ZMQ side and the power of normal object semantics on the QT side. How can we bring these together? On Mon, Jan 27, 2014 at 5:00 PM, Justin Karneges jus...@affinix.com wrote: Mapping ZeroMQ sockets to Qt signals/slots would be wild. :) None of the existing libs attempt anything like this. I'd have to think more about the use cases. On 01/27/2014 01:39 PM, Lindley French wrote: Question: One of the drawbacks of QT's signals and slots mechanism (which is otherwise great) is that it supports many-to-one (like ZMQ pull or sub) and one-to-many (like ZMQ pub), but it does't support one-to-any (like ZMQ push). Is there anything in any of these projects that addresses this in any way by merging the QT and ZMQ functionality somehow? On Mon, Jan 27, 2014 at 2:00 PM, Justin Karneges jus...@affinix.com mailto:jus...@affinix.com wrote: Hi Goswin, On 01/27/2014 03:46 AM, Goswin von Brederlow wrote: On Sun, Jan 26, 2014 at 11:34:13PM -0800, Justin Karneges wrote: There are a few options: https://github.com/wttw/zeromqt https://github.com/jonnydee/nzmqt https://github.com/jkarneges/qzmq It sounds like you've downloaded zeromqt. The project should contain README.markdown. I am the author of QZmq and can help with it if you'd like. Can you give a few words of what makes each of them good or bad please? Why did you start your own project instead of using on of the other two? It's been a year and a half since I created QZmq, so I cannot remember the exact reason, but I believe it was because neither Zeromqt nor Nzmqt supported fully event-driven reads and writes (at least at the time), and I didn't agree with the headers-only style of development used by Nzmqt so I thought I'd try my own rather than contribute. So the advantage of QZmq is it supports write notifications, and it also includes a Valve class which makes it easy to implement backpressure. Probably one should choose between Nzmqt or QZmq. I believe Zeromqt has gone unmaintained, and its own documentation suggests uses Nzmqt instead. Justin ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org mailto:zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
[zeromq-dev] Implementation of ZeroMQ on a Spark Core (Arduino)
Hello, I am looking to have an implementation of ZeroMQ on a Spark Core (spark.io). These modules are made of STM32 microcontroller (ARM 32bits Cortex M3 @ 72MHz) and a WiFi chip from TI. More info here: http://docs.spark.io/#/hardware. They also run Arduino by default. Despite the scarce resources compared to a usual computer, I am hopeful of getting at least a small subset of ZeroMQ's features on it :). There are some socket functions available which seems rather correct for such a small device. Here are their definitions: https://github.com/spark/core-common-lib/blob/master/CC3000_Host_Driver/socket.h In brief, only AF_INET domain is supported, SOCK_STREAM, SOCK_DGRAM and SOCK_RAW types, and IPPROTO_TCP, IPPROTO_UDP and IPPROTO_RAW protocols. You have the rest of the API: accept, bind, listen, connect, select, recv, send, [g/s]etsockopt, gethostbyname, and a few others. I have two questions now: - Do you think with this socket API we can fairly well implement main features of ZMQ? (all ZMQ sockets over tcp at least)? - If yes, I will have two options to do it. Either I attempt to recompile some parts of the original libzmq. Or I implement from scratch 23/ZMTP (or maybe starting with 15/ZMTP?). In the former case, I will have to deal with other restrictions in the system API. It is simply not a full fledged one. And it don't have multitasking. They are planing to implement at least two tasks, one for the application-logic, one for the communication layer. They are also talking about having more real multitasking, but at the cost of very few memory left for the user program... Therefore, the current architecture of libzmq with its IO-thread(s) and API-thread could not have a close match on such target :S. So, my questions on this one is, if I try to take libzmq and flesh it out to only pick what I need, will I stumble upon many exotic system calls? Is it realistic considering your knowledge of the internals of libzmq? Also, will the threading approach of libzmq get in my way, in your opinion? Looking forward to reading your answers, Axel ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] Implementation of ZeroMQ on a Spark Core (Arduino)
The simplest option will be to rewrite small ZMTP stacks from scratch. It's not hard, if you don't care about high performance and concurrency. https://github.com/zeromq/zmtp has some examples. The PicoZMQ project likewise has a simple ZMTP stack. You can dispense with the whole socket paradigm and aim for SUB objects, PUB objects, etc. On Mon, Jan 27, 2014 at 7:51 PM, Axel Voitier axel.voit...@gmail.com wrote: Hello, I am looking to have an implementation of ZeroMQ on a Spark Core (spark.io). These modules are made of STM32 microcontroller (ARM 32bits Cortex M3 @ 72MHz) and a WiFi chip from TI. More info here: http://docs.spark.io/#/hardware. They also run Arduino by default. Despite the scarce resources compared to a usual computer, I am hopeful of getting at least a small subset of ZeroMQ's features on it :). There are some socket functions available which seems rather correct for such a small device. Here are their definitions: https://github.com/spark/core-common-lib/blob/master/CC3000_Host_Driver/socket.h In brief, only AF_INET domain is supported, SOCK_STREAM, SOCK_DGRAM and SOCK_RAW types, and IPPROTO_TCP, IPPROTO_UDP and IPPROTO_RAW protocols. You have the rest of the API: accept, bind, listen, connect, select, recv, send, [g/s]etsockopt, gethostbyname, and a few others. I have two questions now: - Do you think with this socket API we can fairly well implement main features of ZMQ? (all ZMQ sockets over tcp at least)? - If yes, I will have two options to do it. Either I attempt to recompile some parts of the original libzmq. Or I implement from scratch 23/ZMTP (or maybe starting with 15/ZMTP?). In the former case, I will have to deal with other restrictions in the system API. It is simply not a full fledged one. And it don't have multitasking. They are planing to implement at least two tasks, one for the application-logic, one for the communication layer. They are also talking about having more real multitasking, but at the cost of very few memory left for the user program... Therefore, the current architecture of libzmq with its IO-thread(s) and API-thread could not have a close match on such target :S. So, my questions on this one is, if I try to take libzmq and flesh it out to only pick what I need, will I stumble upon many exotic system calls? Is it realistic considering your knowledge of the internals of libzmq? Also, will the threading approach of libzmq get in my way, in your opinion? Looking forward to reading your answers, Axel ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
