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

[Martin Sustrik]

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