[zeromq-dev] Java API is not notifed of C++ assert failures.

[Vladimir & Mihaela]

Martin,

My development environment for my toy project is indeed Windows, but my
question was referring to the best numbers that are available on any 0MQ
supported platform, such that I come up with an architecture that meets my
requirements from the get go and does not need to be changed along the way.

Regarding the "message routing:" if DIS creates the global queue disQ and
both SIM1 and SIM2 connect their local exchanges to disQ, doesn't it mean
that both SIM1 and SIM2 are interested in what DIS has to say? Otherwise
they would create separate point to point connections. But you have shunned
that alternative already. I assume you mean to allow somehow the application
to specify which messasges get routed to which subscriber. Is my assumption
correct?

Vladimir

-----Original Message-----
From: Martin Sustrik [mailto:sustrik at fastmq.com]
Sent: Wednesday, April 15, 2009 11:56 AM
To: Vladimir & Mihaela
Cc: Tamara Kustarova; zeromq-dev at lists.zeromq.org
Subject: Re: [zeromq-dev] Java API is not notifed of C++ assert
failures.


Hi Vladimir,

> Questions:
>
> (1) what is the limit in the number of exchange to queue bindings? I
assume
> it's related to the maximum number of sockets available on a machine. What
> would that limit be? In the hundreds, thousands?

You are working on Win32 platform, right?

There are two aspects to consider.

First one is the system-wide limit for open sockets. This article seems
to discuss the problem:

http://support.microsoft.com/default.aspx?scid=kb;en-us;196271

No guarantee though.

Second, 0MQ uses 'select' function to poll on the sockets. By default
select handles at most 64 sockets on Win32. The limit can be increased
by defining FD_SETSIZE macro to desired value before including winsocks
(select_thread.hpp/cpp). Maybe we should increase it to some reasonable
value ourselves (256?)

In the long run, it would be useful to implement support for Win32 IOCP.
The infrastructure is in place, so it shouldn't be too hard, but the
issue has low priority right now.

> (2) is there an unbind function? If the number above is low then I am
> thinking to close connections that are rarely used and reopen them when
> needed. I could go with a different approach if an unbind is not
available.

No, there's no unbind.

> Martin, along the lines in Holger's message,
>
> (3) here is a scenario that may run into trouble if bind asserts and kills
> my process; it can be even used maliciously to bring down my system as
well.
>
> Process DIS creates a global queue and a global exchange. There are
multiple
> SIM processes that communicate with DIS via DIS' global objects. However,
in
> this case each SIM will receive messages targeted to other SIMs and will
> have to filter out the ones that it is not interested in.

Right. Message routing. This should be done in 0MQ, it's on roadmap and
it eventually will be done.

> An alternative is
> to have each SIM create a global pair of objects for point to point
> communication with DIS. In this case DIS will have to bind to each SIM's
> global objects. So, a malicious strategy to bring down DIS would be to
> connect to SIM, ask it to bind to SIM's newly created objects and
> immediately exit. DIS will try to bind and will kill itself, bringing down
> the entire system.

Not a good idea. SIM should bind to DIS and not the other way round.

Therefore the only viable architecture is the first one,
> with its disadvantages - added traffic on the network, each process
> filtering out what it does not need, etc.

Ack. As already mentioned 0MQ should filter out unneeded messages on the
sender side. That's the systematic solution. We're gradually moving in
that direction. Obviously, contributing the code or sponsoring the
development would speed the whole thing up.

Martin