[prev in list] [next in list] [prev in thread] [next in thread] 

List:       zeromq-dev
Subject:    Re: [zeromq-dev] Implementation of ZeroMQ on a Spark Core (Arduino)
From:       Pieter Hintjens <ph () imatix ! com>
Date:       2014-01-28 5:57:46
Message-ID: CADL5_siZJj9hqSwgae15wAvcs-FOyXWctyKKgyDD+L_5dZJf7g () mail ! gmail ! com
[Download RAW message or body]

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.voitier@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
[prev in list] [next in list] [prev in thread] [next in thread]