>> I like the symmetric design — that way nothing is ignored, like
>> Pieter suggests.  And it also matches the TCP case better.  In the
>> TCP case, there's a buffer of SNDHWM messages on one side, and a
>> buffer of RCVHWM messages on the other.  So in the inproc case, there
>> should be a single buffer of SNDHWM+RCVHWM messages.
> 
> Ok. That would require passing each peer's HWM to the other peer. So 
> that both can compute and use sum HWM instead of the original local HWM.
> 
> In short:
> 
> 1. There's ctx_t::register_endpoint function which register inproc 
> endpoint with the context. We can store bind()er's HWM there.
> 
> 2. When connect()er retrieves the ednpoint, it would get bind()er's HWM 
> along with it, it will add the two HWMs and initialise the newly created 
> pipe accordingly.

Oh, I though this would just be for inproc connections.  As in, the total size 
of all buffers should be SNDHWM + RCVHWM.  For TCP, there are buffers on either 
side of the network connection, and so you get this by having one side create a 
SNDHWM buffer, and the other create a RCVHWM buffer.  It's only in the inproc 
connection — where there's only a single buffer — where you'd have to add 
together the values to get the correct buffer size.

–doug


Attachment: PGP.sig
Description: This is a digitally signed message part

_______________________________________________
zeromq-dev mailing list
[email protected]
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Reply via email to