[nanomsg] Re: Introduction and questions
- From: Gonzalo Diethelm <gonzalo.diethelm@xxxxxxxxx>
- To: Martin Sustrik <sustrik@xxxxxxxxxx>
- Date: Mon, 24 Jun 2013 10:25:20 -0400
That separation sounds good. I would expect that the implementation of
transports doesn't know anything about protocols, and protocols don't know
anything about transports; both of them should only know about core, which
implements the glue between them.
Can you think of a really minimal subset of nanomsg that one could design
and implement? Something like "one protocol, one transport, minimal core"?
On Mon, Jun 24, 2013 at 2:21 AM, Martin Sustrik <sustrik@xxxxxxxxxx> wrote:
> Hi Gonzalo,
>
>
> Therefore, one must answer:
>> what should be ported to Go?
>>
>> One way to approach this, as it was already pointed out, would be
>> defining the nanomsg protocol and implementing that in Go. Perhaps
>> another approach could be implementing an even more low-level
>> "communications and synchronization engine" in Go that allows you to
>> then implement something like the nanomsg protocol on top of that. This
>> might even make it possible to implement the ZeroMQ protocol on top of
>> that as well (if that makes any sense)... Still, you would have to
>> clearly state what this really low-level engine should be composed from.
>> Perhaps this is exactly what nanomsg has accomplished; I really need to
>> look into the code in more details.
>>
>
> In the C codebase the highest-level architecture looks like this:
>
> 1. Core functionality
> 2. Transports
> 3. Protocols
>
> The core does the job of connecting transports (tcp, ipc, etc.) to
> protocols (req/rep, pub/sub, etc.) and then to the API.
>
> Transports handle functionality that is specific to a transport,
> irrespective of the protocol running on the top of it. So, for example, TCP
> transport implements delimitation of messages within TCP bytestream etc.
>
> Protocols handle the functionality that is specific to the messaging
> pattern, irrespective of the transport beneath it. So, for example,
> implementation of subscriptions goes to pub/sub protocol.
>
> When porting nanomsg, I would suggest keeping this clear separation of
> core/transports/protocols. I haven't done that in ZeroMQ and the
> consequence is that it's very hard to add new transports and/or protocols.
>
> Just my 2c.
> Martin
>
>
--
Gonzalo Diethelm
gonzalo.diethelm@xxxxxxxxx
Other related posts:
