- Message d'origine -
> +Bit 1 (LABEL): _This message part is not part of the original
> +message._ A value of 1 indicate a message part that weren't part of
> +the original stream. They are used internally by the transport to
> +indicate, for example, the origin of a message.
> +
> +Bits
> Feature 2 - Embedded flags inside the msg_t structure.
>
> By allowing frame flags to be set inside the msg_t structure, it would
> be far easier to keep forward compatibility with new flags for proxy
> device that need to copy msg frames in a transparent manner. Just as an
> example, a queue so
flags
together. Hope it is useful (and it should take much more CPU :) ).
Tell me if anything wrong with it,
Thanks,
Fabien
>From f519fccdbc796c6bd9a870b8150060087fc63bcd Mon Sep 17 00:00:00 2001
From: Fabien Ninoles
Date: Fri, 20 May 2011 20:58:46 -0400
Subject: [PATCH] Add msg_t::la
+1: It answers a question I was still asking myself if this was enough :).
Fabien
-Message d'origine-
De : zeromq-dev-boun...@lists.zeromq.org
[mailto:zeromq-dev-boun...@lists.zeromq.org] De la part de Martin Sustrik
Envoyé : 19 mai 2011 18:41
À : 0MQ development list
Objet : [zeromq-de
> De : zeromq-dev-boun...@lists.zeromq.org
> [mailto:zeromq-dev-boun...@lists.zeromq.org] De la part de Martin Pales
> Envoyé : 19 mai 2011 04:20
> À : ZeroMQ development list
> Objet : Re: [zeromq-dev] ZMTP/1.1 - proposal
>
> regarding the (lack of) version number and exchange/validation of conte
We can enter a bug stating that ZMQ 2.1 will crash when connected with 2.2/3.0
sockets. Couldn't we consider forward incompatibility as a bug ?
Otherwise, we could wait and see if the change really break 2.1. I don't think
any 2.1 sockets would break on new flags, and if we can introduce the n
Also, in the gaming industry, most of our stuff have exception deactivated.
Performance is the main reason here: exception create an overhead that isn't
compensate by error handling (error handling ? in a game ? what's that ? ;) ).
Fabien
-Message d'origine-
De : zeromq-dev-boun...@
- Message d'origine -
> The preferred way to adding new features is working with master (libzmq
> repo).
Thanks very much. The code is quite clean so that should be easy to do.
> > > > > Feature 4 - Add a ready sockopt.
> I guess I don't understand what the option is meant to do. Skip
5/15/2011 06:35 AM, Pieter Hintjens wrote:
> > On Sun, May 15, 2011 at 1:25 AM, Fabien Ninoles
> > wrote:
> >
> >> Here the feature set: Feature 1 - Add a new msg LABEL flag marking
> >> a frame as "labeled".
> >
> > Part of redesigning the
I just terminated most of my porting of the P2P layer of our cluster to
ZMQ, (ab-)using a lot the collector device I have presented last week
(see http://www.tzone.org/~fabien/hg/index.cgi/collector/). I find out
that it shared a lot with two other pattern used in ZMQ, the PUB socket
and the LRU d
> I've been playing with zmq and its great, I want to use it to enable our 5
> servers to push out logging messages to a log server to store it
> centrally. Some people would set the 5 servers up as publishers with the
> log server as a subscriber, but that requires the log server to know where
> a
> -Message d'origine-
> De : Martin Sustrik [mailto:sust...@250bpm.com]
> Envoyé : 9 mai 2011 01:19
> À : Fabien Ninoles; ZeroMQ development list
> Objet : Re: [zeromq-dev] Feedback on new PATCH socket
>
> If what you meant was propagating an "END&qu
-Message d'origine-
De : Martin Sustrik [mailto:sust...@250bpm.com] Envoyé : 9 mai 2011 05:59 À :
Fabien Ninoles; ZeroMQ development list Objet : Re: [zeromq-dev] Feedback on
new PATCH socket
> I meant replacing MORE flag by LABEL flag. That would mean removing
> multi-part
OK, I give a second look to the collector pattern I wrote and build a basic
prototype using a variation on the LRU queue. I would send the proto once I
get access to a computer where I can test it (my N900 doesn't have a pyzmq
package and the debian package depends on a more recent toolchain) b
> > However, one way to be more transparent is to mark a frame as being
> > "added" to the original message instead of using the empty delimiter.
> > This will allow REQ/REP to work directly without change. The flag
> > need to be pass between sockets however (just like the MORE flag) and
> > s
> This won't work. The peer can be a device rather than an endpoint. In
> such case you should expect to get arbitrary number of responses from a
> single connection.
My bad... The code should loop on the RCVMORE condition and send a full
message. Also, take note that it only discard a socket
I'm not sure about how 190 can be fixed by separating the semantic of the
ROUTER from the req/rep socket; propagating a disconnection from one edge to
another could be quite hard and probably hardly possible if you have any
fairqueuing in-between.
However, one way to be more transparent is to m
kets with a single one. Can't work with the
> collecting mechanic I talk below however (neither with a timeout). May
> be we should put this policy in a higher level socket ?
>
> Fabien
>
> - Message d'origine -
> >
> > - Message d'origine
ssage d'origine -
>
> - Message d'origine -
> > On 05/06/2011 10:15 PM, Fabien Ninoles wrote:
> > > Census is just one example. It's more a "chain of command" pattern
> > > where one or multiple GOVERNOR can send a command, to one
- Message d'origine -
> On 05/06/2011 10:15 PM, Fabien Ninoles wrote:
> > Census is just one example. It's more a "chain of command" pattern
> > where one or multiple GOVERNOR can send a command, to one or multiple
> > WORKERS that obeys and sen
ould probably find some interesting usage (like multipart reply).
Hope this help,
Fabien
-Message d'origine-
De : Martin Sustrik [mailto:sust...@250bpm.com]
Envoyé : 6 mai 2011 15:20
À : ZeroMQ development list
Cc : Fabien Ninoles
Objet : Re: [zeromq-dev] Feedback on new PATCH soc
The new patch socket works great. I test in on Windows, with simple prototype,
both with inproc and tcp. My prototype is written in python (with a custom
ctypes binding) and start around 150 threads connecting in a five-level
hierarchy, with 3 middlelevel devices, and 5 differents entry points
e can specified the recipients (or group of recipients), and all
nodes that are not part of them shouldn't respond.
Fabien
-Message d'origine-
De : Martin Sustrik [mailto:sust...@250bpm.com]
Envoyé : 6 mai 2011 02:04
À : ZeroMQ development list
Cc : Fabien Ninoles
Objet :
Thanks very much, what a service ! :)
What's the protocol for socket validation ? Could I bind it to an XREP/XREQ ?
I will try to test it before the end of the week . Coming back soon.
Thanks again,
Fabien
-Message d'origine-
De : zeromq-dev-boun...@lists.zeromq.org
[mailto:zeromq-de
De : zeromq-dev-boun...@lists.zeromq.org
[mailto:zeromq-dev-boun...@lists.zeromq.org] De la part de Pieter Hintjens
Envoyé : 5 mai 2011 11:15
À : ZeroMQ development list
Objet : Re: [zeromq-dev] Broadcasting Requests
On Thu, May 5, 2011 at 4:54 PM, Fabien Ninoles
wrote:
> Moreover, sin
Hello,
I'm quite new to zeromq but already have implement it in a couple of complex
clustering setup. So far, so good, performance is awesome and thanks a lot for
this wonderful library.
My current challenge is to be able to broadcast a request to multiple node and
collect back the results of
26 matches
Mail list logo
