<p dir="ltr">Hi,</p>
<p dir="ltr">All transports going through process boundaries must go through kernel, so it will use fd in any case.</p>
<p dir="ltr">If you can change your code to use threads instead, then you can use inproc transport, which simply pass pointers.</p>
<div class="gmail_extra"><br><div class="gmail_quote">Dne 19. 7. 2016 21:10 napsal uživatel "Doron Somech" <<a href="mailto:somdoron@gmail.com" target="_blank">somdoron@gmail.com</a>>:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">I think IPC also use FD per connection but not sure. PGM is one FD per sender/receiver, I think. </p>
<p dir="ltr">However,  I don't think you should worry about that,  OS is there to handle ten of thousands of FD,  just configure correctly.  Also maybe linux server and linux desktop have different settings. </p>
<div class="gmail_extra"><br><div class="gmail_quote">On Jul 19, 2016 20:49, "Alexander Poddey" <<a href="mailto:alexander.poddey@gmx.net" target="_blank">alexander.poddey@gmx.net</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Ah, ok, now I understand.<br>
I guess using IPC should solve the problem for processes on the same<br>
cluster-node. If so, I could use a tcp bride between nodes, and IPC locally.<br>
<br>
How about PGM?<br>
<br>
Alexander<br>
<br>
<br>
Doron Somech wrote:<br>
<br>
> It is not zeromq, its TCP, when you have 10K open connections you are<br>
> using 10K file descriptors, there is no wonder here, that how TCP works.<br>
> HAProxy and nginx for example do the same, or any webserver, if you want<br>
> to support 10K concurrent connections you must increase the maximum<br>
> sockets per application.<br>
><br>
> Take a look a the accept socket docs:<br>
><br>
> <a href="http://man7.org/linux/man-pages/man2/accept.2.html" rel="noreferrer" target="_blank">http://man7.org/linux/man-pages/man2/accept.2.html</a><br>
><br>
> On Tue, Jul 19, 2016 at 7:12 PM, Alexander Poddey<br>
> <<a href="mailto:alexander.poddey@gmx.net" target="_blank">alexander.poddey@gmx.net</a>> wrote:<br>
><br>
>> Hmm,<br>
>><br>
>> on linux, the number of file descriptors per process is limited<br>
>> (typically to 1024). The total limit on my machine (kernel limit is ~734<br>
>> 000 opened files).<br>
>><br>
>> This means a process can accept only 1024 connections?!?<br>
>><br>
>> I can tweak the limit as super user of that machine; this however is no<br>
>> good<br>
>> solution.<br>
>> Think of my agent simulation running on a server where I'm not root. Then<br>
>> each process can accept only 1024 connections which is way to few...<br>
>><br>
>> I wonder why zmq needs a file descriptor per connection...<br>
>><br>
>> Alexander<br>
>><br>
>><br>
>><br>
>> Doron Somech wrote:<br>
>><br>
>> > I'm  not sure I  understand,  each file descriptor is a socket.  When<br>
>> > zeromq accept tcp socket another file descriptor is created. OS should<br>
>> > be able to manage thousands and tens of thousand open descriptor.<br>
>> ><br>
>> > On Jul 19, 2016 6:56 PM, "Alexander Poddey" <<a href="mailto:alexander.poddey@gmx.net" target="_blank">alexander.poddey@gmx.net</a>><br>
>> > wrote:<br>
>> ><br>
>> >><br>
>> >> Essentially, the question is:<br>
>> >> why does ZMQ consume file descriptors at all?<br>
>> >><br>
>> >><br>
>> >><br>
>> >><br>
>> >> > Hi,<br>
>> >> ><br>
>> >> > I have a setup in C++ on linux where a master process is setting up<br>
>> >> > a ZMQ_ROUTER and then forks many child processes, which then connect<br>
>> >> > to<br>
>> >> that<br>
>> >> > router (tcp protocol).<br>
>> >> > Whenever a child zmq_connect's to the master, a file descriptor is<br>
>> >> > occupied (and assigned to the master process). They get free'ed fine<br>
>> >> > when the connection is close.<br>
>> >> ><br>
>> >> > This however limits the number of interacting processes to the<br>
>> >> > number of allowed file descriptors (per process). For me (linux),<br>
>> >> > this currently is 1024, which is way to small for my intended use<br>
>> >> > (multi-agent / swarm simulation).<br>
>> >> ><br>
>> >> > Can I prevent this behaviour?<br>
>> >> > In my mesaging architecture, each agent connects to 6 sockets, so<br>
>> >> > with<br>
>> >> 100<br>
>> >> > agents I end up with 600 occupied file descriptors :-(<br>
>> >> ><br>
>> >> > Alexander<br>
>> >> ><br>
>> >> ><br>
>> >> > _______________________________________________<br>
>> >> > zeromq-dev mailing list<br>
>> >> > <a href="mailto:zeromq-dev@lists.zeromq.org" target="_blank">zeromq-dev@lists.zeromq.org</a><br>
>> >> > <a href="http://lists.zeromq.org/mailman/listinfo/zeromq-dev" rel="noreferrer" target="_blank">http://lists.zeromq.org/mailman/listinfo/zeromq-dev</a><br>
>> >><br>
>> >><br>
>> >> _______________________________________________<br>
>> >> zeromq-dev mailing list<br>
>> >> <a href="mailto:zeromq-dev@lists.zeromq.org" target="_blank">zeromq-dev@lists.zeromq.org</a><br>
>> >> <a href="http://lists.zeromq.org/mailman/listinfo/zeromq-dev" rel="noreferrer" target="_blank">http://lists.zeromq.org/mailman/listinfo/zeromq-dev</a><br>
>><br>
>><br>
>> _______________________________________________<br>
>> zeromq-dev mailing list<br>
>> <a href="mailto:zeromq-dev@lists.zeromq.org" target="_blank">zeromq-dev@lists.zeromq.org</a><br>
>> <a href="http://lists.zeromq.org/mailman/listinfo/zeromq-dev" rel="noreferrer" target="_blank">http://lists.zeromq.org/mailman/listinfo/zeromq-dev</a><br>
>><br>
<br>
<br>
_______________________________________________<br>
zeromq-dev mailing list<br>
<a href="mailto:zeromq-dev@lists.zeromq.org" target="_blank">zeromq-dev@lists.zeromq.org</a><br>
<a href="http://lists.zeromq.org/mailman/listinfo/zeromq-dev" rel="noreferrer" target="_blank">http://lists.zeromq.org/mailman/listinfo/zeromq-dev</a></blockquote></div></div>
<br>_______________________________________________<br>
zeromq-dev mailing list<br>
<a href="mailto:zeromq-dev@lists.zeromq.org">zeromq-dev@lists.zeromq.org</a><br>
<a href="http://lists.zeromq.org/mailman/listinfo/zeromq-dev" rel="noreferrer" target="_blank">http://lists.zeromq.org/mailman/listinfo/zeromq-dev</a><br></blockquote></div></div>