[nanomsg] Re: Interprocess communication on same host
- From: "Garrett D'Amore" <garrett@xxxxxxxxxx>
- To: "nanomsg@xxxxxxxxxxxxx" <nanomsg@xxxxxxxxxxxxx>
- Date: Fri, 5 Sep 2014 16:43:56 -0700
In my experience, people vastly underestimate the performance of bcopy.
Unless you are passing around vast amounts of data (why are you using
something like nanomsg in that case, btw?) it simply doesn't pay off.
You lose the intended performance gains in the extra complexity and locking.
To make this work well (and this would not be portable outside of the
platform barring unusual measures like RDMA), you'd need a collaboration
layer, a very large shared memory region, and some kind of ring or consume
and produce indices in the buffer. Probably better to have two separate
buffers, one for each direction, with different MMU settings (cache
coherency).
This also becomes really fragile. A bug in one program can now take out
the other, unless you're very careful to treat the shared memory region
with the same kind of care that you do packet data. (i.e. don't pass
around program state, or pointers, etc.) Don't assume that the other side
won't trash the memory.
There may be some extreme cases where this complexity is worthwhile; you
*could* use nanomsg to do that. But again, why? I'd just map the data up,
and use POSIX signaling & mutexes to coordinate access. My guess is that
this will be simpler than trying to coordinate across a simulated network.
I have a hard time imagining that I'd want to forward data received from
this over some kind of device to other parties in the nanomsg
infrastructure, which is why I don't see much call to make this work with
nanomsg.
On Fri, Sep 5, 2014 at 2:30 PM, Ron Gonzalez <dmarc-noreply@xxxxxxxxxxxxx>
wrote:
> Sorry, but I don't understand. When you say that all the infrastructure to
> do that is already implemented, what piece is implemented? Are you
> referring to batching up messages?
>
> Would it be valuable to look into contributing shmem management at a lower
> level?
>
> Thanks,
> Ron
>
>
> On 09/05/2014 11:54 AM, Martin Sustrik wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 05/09/14 18:18, Ron's Yahoo! (Redacted sender zlgonzalez@xxxxxxxxx
>> for DMARC) wrote:
>>
>>> Thanks Martin. Wouldn’t we always be able to batch messages up such
>>> that we would always get > 1MB thereby resulting in larger net
>>> throughput? This assumes a non-realtime use case of course…
>>>
>> In the current design you can do that on application level: Collect
>> messages for time T, then send the whole batch as a single message.
>>
>> It doesn't work the other way round though: If nanomsg did extensive
>> batching it would not be suitable for real-time use cases.
>>
>> That being said, shmem would still be valuable for transporting very
>> large messages between processes on the same box. Btw, all the
>> infrastructure to do that is already implemented, what's missing is
>> the actual piece of code for managing shmem.
>>
>> Martin
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.11 (GNU/Linux)
>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>>
>> iQEcBAEBAgAGBQJUCgbjAAoJENTpVjxCNN9Y9kcH/ifmT5nHU6iBh9k/Yd94CEq7
>> voB4oZV8FOo6QOHcWGL1pY5vSWZs4D/3dIMukfmsDhtsyr8oIO3iyY8jtdnH2Hv6
>> zABDUSlPpaHLQ4TvruQ+/ZMR3tB0ZN50wLK/orTHvHXNG0fhEqsDkcSjLZHLufDs
>> aMDUbO3Y0kAsow6lmdZ2xffoGwzrlkiLF9MmzIM86fREvmDyolqHblvK51nV1XlY
>> BWge6UfuYLmgJDsNWhkcvYq/z5StiFBXtPYrMWygm+RIcBgaBMiBcsCboi3ZeS/0
>> aNF8sz+InmyL9Arw/MBxQTda+Re01i1fjGVPsxfIE1A24+qZzaI18uCkA0kT00M=
>> =0t3u
>> -----END PGP SIGNATURE-----
>>
>>
>
>
Other related posts:
