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
