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
