question on using INADDR_LOOPBACK in ev_pipe
timna2 at gmail.com
Fri Nov 30 20:37:16 CET 2018
okay - thanks for your response.
So far I have asked our customers to lower restriction or make exception to
our app solely because of this issue of using local loop ip. It worked
well until we are getting a lot more customers to handle and most of them
(95%) are windows users. These majority users in enterprise world with IT
folks who are paranoid about security to install top security anti-virus to
its highest restriction don't get these things and they are simply annoyed
when things doesn't work.
I know the work involved to migrate from libevent to libuv wouldn't be easy
as I looked thru the APIs but I guess I will have to bite the bullet and
find some workaround somehow.
On Fri, Nov 30, 2018 at 10:53 AM Marc Lehmann <schmorp at schmorp.de> wrote:
> On Thu, Nov 29, 2018 at 02:57:29PM -0800, Tim Na <timna2 at gmail.com> wrote:
> > Sorry about that silly mistake (or threats) - I just learned not to use
> > company's email system for such request now. Sincere apologies for such
> > annoyance to you and libev community.
> > However, I question still stands and I am looking at libuv as alternative
> > choice as it seems to have no such limitation as libevent or libev.
> There is no limitation in libevent or libev, what you describe is a bug or
> misconfiguration of other components on your system (basically, you are
> saying that using TCP/IP is a limitation in libev, this is silly). If you
> disable your broken virus scanner of whatever causes the problems things
> start to work (this also affects firefox and many other programs which
> are forced to poll if they can't get a local socket to work, i.e. they
> might superficially work, but only because they run a 100Hz timer in the
> background and poll for events).
> Another option would be to switch to an OS such as GNU/Linux, which
> doesn't have the limitations of the windows platform (you haven't
> mentioned what platform you are using, but it sure sounds like windows) -
> both in terms of broken virus scanners/firewalls breaking the TCP/IP stack
> and in lacking efficient local sockets.
> You could also try libuv, although my personal totally unbiased opinion is
> that libuv suffers from many design bugs that more mature libraries such
> as libev (or libevent) do not suffer from because libuv was designed by
> people unknowledgable in event systems and therefore were bound to repeat
> many mistakes of earlier ad-hoc event libraries.
> Of course, if you don't care about correctness and just want to make
> things superficially working, then you could call it a limitation in
> libevent/libev and use libuv, if that works for you (and unknowingly
> suffer later because you run into design issues you wouldn't notice with
> better event libraries).
> A real reason to switch to libuv is performance - libev doesn't do I/O for
> you, and this tends to make it slow on windows, which doesn't support I/O
> readyness notifications efficiently. libuv _does_ do I/O for you and might
> be more performant if all you can use is windows. OTOH, if all you can use
> is windows, you clearly don't care about performance much, so why bother
> Using libuv in this way will also require to rewrite any existing
> event-based code to be I/O-based instead which might or might not be an
> The choice of a Deliantra, the free code+content
> -----==- _GNU_ http://www.deliantra.net
> ----==-- _ generation
> ---==---(_)__ __ ____ __ Marc Lehmann
> --==---/ / _ \/ // /\ \/ / schmorp at schmorp.de
> -=====/_/_//_/\_,_/ /_/\_\
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the libev