Hi @ all! I'm developing against ZMQ for quite some time now and the distributed service architechture is ready and working stable (also under heavy load).
(No, I din't update to the latest version because the behaviour doesn't look like an accidential bug) While hardening the system, a queer (but absolutely constant) behaviour was found. This seems to be a feature and no bug, so I wonder if I am thinking in the wrong way ... and where exactly my mistake is located, or if the design of my architecture is wrong or if ZMQ's behaviour is wrong: architecture is as follows: - I first launch one or more (modified) zmq LRU queues. - the service queues BIND a service port to which clients and other services will CONNECT later. - the "internal side" of the LRU queues also BIND a socket to which the service worker instances CONNECT later for servicing requests etc. This architecture uses PUP/SUB as well as REQ/REP for sending requests to a single service instance (normal work) or for broadcasting (initialisation, shutdown of ALL servies or other thing to be done by each service instance etc.). As I said, the SERVICE (SERVER) SIDE does a BIND (of course ;-) Now the CLIENT SIDE comes along and CONNECTS to the service ports ... working fine! BUT: as soon as I misconfigure the system accidentially and try to e.g. connect a client to a service port BUT USE A WRONG SOCKET TYPE (e.g. the client creates a PUB socket and tries to connect to the service's PUB port), then the following happens: - the errorneously CONNECTING CLIENT gets a >>>handable<<< error return - the correctly bound SERVICE >>>ASSERTS<<< and is dead ... not handable !!! My question: Why does the BINDING (server) side assert() and the CONNECTING (client) side stays controllable by my code. Shouldn't this be exactly the other way? The current implementation ensures that the server crashes (via assert) which the offending client keeps running happily. lg sven -------------------------------------------------------- E = mc² ± 2dBA ----- everything is relative -------------------------------------------------------- _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
