On Wed, 01 Dec 2010 07:28:25 +0100 Christophe Zbierski <czbierski <at> wanadoo.fr> wrote: > Hi, is it possible to bind an HTTP server on unix socket instead of > address and port (int evhttp_bind_socket > <http://monkey.org/%7Eprovos/libevent/doxygen/evhttp_8h.html#c0d2930caef8350823771b49c2f31835>(struct > evhttp *http, const char *address, u_short port) ). I don't know fur sure, and I believe it should require some patch. However, I am interested to understand why you are asking that. In particular, at least under Linux, I know unfortunately no Web browser (or other HTTP client) able to send HTTP requests on an Unix socket. I would find extremely useful if there existed (on some Linux browsers) a URL scheme for that. Imagine if opening unixsock:/tmp/somedir/socket//goo/bar?v=x would talk HTTP protocol to a unix socket /tmp/somedir/socket and GET the /goo/bar page with parameter v=x I am not familiar with FireFox internals to implement that. I heard it might even be implemented as a FireFox plugin (but I am not sure). Christophe, do you have such browser extensions in mind, or are you only willing to do HTTP on sockets programmatically, outside of any browser and user web interface? Cheers. -- -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359 8, rue de la Faiencerie, 92340 Bourg La Reine, France *** opinions {are only mine, sont seulement les miennes} *** *********************************************************************** To unsubscribe, send an e-mail to majordomo <at> freehaven.net with unsubscribe libevent-users in the body.
Le Wed, Dec 01, 2010 at 07:47:36AM +0100, Basile Starynkevitch ecrivait : > However, I am interested to understand why you are asking that. > > In particular, at least under Linux, I know unfortunately no Web > browser (or other HTTP client) able to send HTTP requests on an Unix > socket. REST is not a browser-only protocol and has become a standard way for applications to communicate. Also, proxies and web servers like Nginx can accept HTTP connections and pass them to a backend on a Unix socket (still using HTTP). For instance my Simple COMET server (https://github.com/jedisct1/Simple-Comet-Server) uses this in order to provide long-polling to Nginx. The fastest way to use it is to run it on the same server as Nginx, on a Unix socket. But the protocol remains HTTP. -- Frank Denis - j [at] pureftpd.org - http://00f.net - Twitter: <at> jedisct1 *********************************************************************** To unsubscribe, send an e-mail to majordomo <at> freehaven.net with unsubscribe libevent-users in the body.
Le 01/12/2010 07:47, Basile Starynkevitch a écrit : > I don't know fur sure, and I believe it should require some patch. > > However, I am interested to understand why you are asking that. > > In particular, at least under Linux, I know unfortunately no Web > browser (or other HTTP client) able to send HTTP requests on an Unix > socket. > > I would find extremely useful if there existed (on some Linux browsers) > a URL scheme for that. Imagine if opening > unixsock:/tmp/somedir/socket//goo/bar?v=x > would talk HTTP protocol to a unix socket /tmp/somedir/socket and GET > the /goo/bar page with parameter v=x > > I am not familiar with FireFox internals to implement that. I heard it > might even be implemented as a FireFox plugin (but I am not sure). > > Christophe, do you have such browser extensions in mind, or are you > only willing to do HTTP on sockets programmatically, outside of any > browser and user web interface? > > Cheers. > I use nginx as a proxy pop and imap. In this mode, nginx needs a http server for user authentication. The HTTP server is on the same machine as nginx, and I'd like to use a unix socket rather than TCP. *********************************************************************** To unsubscribe, send an e-mail to majordomo <at> freehaven.net with unsubscribe libevent-users in the body.
Hi everybody, I'm new to this list, so please forgive me if this has been discussed. I read the libevent2 book, and it said that bufferevent currently supports only TCP socket. I take a look at the code, and see that, however, it seems that bufferevent can work with UDP too. So my question is why the book said that UDP is not supported? And if that is really the case, what should I do to modify bufferevent so that it supports UDP? Any comment is appreciated, Thai. *********************************************************************** To unsubscribe, send an e-mail to majordomo <at> freehaven.net with unsubscribe libevent-users in the body.
>> It's generated by autoconf *as part of the build process for >> Libevent*. If you build a new libevent with --prefix=/usr and do >> "sudo make install" on it, then you will overwrite >> /usr/include/event2/event-config.h. But if you're using a packaging >> system, then you shouldn't ever do that. >> > Ah, right, so that is applicable only when the libevent package is > built and installed. Right, it should matter not if the Fedora > maintainers do the necessary corrections to the -devel package (rpm) > and, maybe, to autoconf as well to reflect the above change. > > OK, if there are no objections I am submitting this as a bug with > Fedora for them to make the changes. Bug submitted to Fedora - https://bugzilla.redhat.com/show_bug.cgi?id=658858 *********************************************************************** To unsubscribe, send an e-mail to majordomo <at> freehaven.net with unsubscribe libevent-users in the body.
Hi Folks, Maybe someone has done this before so figured I'd ask while I'm still experimenting with possible solutions. In the process of finishing up some porting to OsX I noticed that I have a race condition in my code related to listener sockets. Previously I would just bring up the listener socket, bind it, make it non-blocking, call accept once (dropping any success which should never happen anyway) and then query the port before moving on. Now, with libevent I'm curious if there is a better method of doing this. I started out just using the evconnlistener_new_bind but this is obviously not calling accept immediately on the socket since OsX is functional only if I insert a couple calls to libevent_loop into the code prior to requesting the bound port. (NOTE: Win32 works fine but I assume that is because it calls AcceptEx immediately on the socket.) In a single threaded system this is not a problem but much of this portion of my code is actually running in a worker thread owned by a multi-cast dns (i.e. bonjour/avahi) wrapper. Currently my best guess is to go back to the old method and just use evconnlistener_new instead of the '_bind' variation passing in the socket after I've gotten the required information out of it. Any suggestions are welcome. Preferably in the future, listener might be able to do this fully asynchronously with an event callback or something and then it would all work without any extra front end work or portability issues. KB *********************************************************************** To unsubscribe, send an e-mail to majordomo <at> freehaven.net with unsubscribe libevent-users in the body.
The iocp listener fix posted has a new bug added as: 3124666. Should be able to mark it fixed with the change mentioned previously. KB > -----Original Message----- > From: owner-libevent-users <at> freehaven.net [mailto:owner-libevent- > users <at> freehaven.net] On Behalf Of Nick Mathewson > Sent: Tuesday, November 30, 2010 1:31 PM > To: libevent-users <at> freehaven.net > Subject: [Libevent-users] If you have a patch or a bug, *please* put it on > the bugtracker > > Hi, all. I want to highlight a paragraph from the 2.0.9-rc announcement: > > > We're almost out of known bugs with the 2.0.x series. If you know > > about a bug that 2.0.9-rc does not fix, please have a quick look at > > the bug tracker to make sure that there is an entry there. If there > > is not, then please don't assume that we remember it, even if you > > mentioned it here, or emailed me personally, or such. > > The trackers are here: > http://sourceforge.net/tracker/?group_id=50884 > > Also, if you *do* have a ticket there that you haven't checked in a > while, please go have a look to make sure that it isn't blocking on > some questions we've asked you. > > If there is some reason that you cannot post bugs to sourceforge, drop > me a line and tell me so, and I'll try to figure something out. > > It's hard to write mails like these, since I worry that if I am too > blunt I will sound rude, but I also worry that if I am not blunt > enough, people will continue to use my inbox as a bugtracker, and get > upset when their issues don't get solved. So instead I will try to be > frank: I am bad at remembering to do things sometimes, and my inbox is > far too big and messy to be a good project management tool. If you > have sent a bug report to somewhere besides the bugtracker, or you > have sent a patch to somewhere besides the patchtracker, and it has > not already been fixed/applied, please just act as if it has been > completely overlooked, and post it to the appropriate tracker. > > open-sourcefully yrs, > -- > Nick > *********************************************************************** > To unsubscribe, send an e-mail to majordomo <at> freehaven.net with > unsubscribe libevent-users in the body. *********************************************************************** To unsubscribe, send an e-mail to majordomo <at> freehaven.net with unsubscribe libevent-users in the body.
On Wed, Dec 1, 2010 at 8:22 AM, Thai Duong <thaidn <at> gmail.com> wrote: > Hi everybody, > > I'm new to this list, so please forgive me if this has been discussed. > I read the libevent2 book, and it said that bufferevent currently > supports only TCP socket. I take a look at the code, and see that, > however, it seems that bufferevent can work with UDP too. The evbuffer backend that bufferevents uses to store incoming and outgoing data currently assumes that it's handling stream data rather than datagrams, and as such does not preserve packet boundaries when reading and writing. There are probably other issues as well, but that one's enough of a showstopper to make bufferevents+UDP unworkable in the current code base. > So my > question is why the book said that UDP is not supported? Because it's the truth. > And if that > is really the case, what should I do to modify bufferevent so that it > supports UDP? It will probably take a fair amount of programming. You'd want to start by thinking about the appropriate abstractions at the evbuffer level, and then considering which abstractions are appropriate for making evbuffers work on packets rather than streams without making either implementation inefficient or making either API ugly or hard to use. At the same time, you'd want to have a look through the bufferevent code and see what stream-only assumptions (if any) it makes, and what would need to be done to fix those. Etienne Samson was working on a design for this a while back, and I'd like to revisit it for Libevent 2.1. You can have a look at the state of his work here: https://sourceforge.net/tracker/?func=detail&aid=2928202&group_id=50884&atid=461324 . It makes some choices that I didn't agree with at the time, though to be honest I haven't looked at it recently and can't currently remember which they were. This is also probably a good time to apologize to Etienne for being so slow here; the Libevent 2.0 release cycle has been entirely too long. Once 2.0.x-stable is out, it's probably a good idea to consider ways to make sure that 2.1 does not spend so long in alpha as 2.0.x did. yrs, -- -- Nick *********************************************************************** To unsubscribe, send an e-mail to majordomo <at> freehaven.net with unsubscribe libevent-users in the body.
On Wed, Dec 1, 2010 at 1:28 AM, Christophe Zbierski <czbierski <at> wanadoo.fr> wrote: > Hi, is it possible to bind an HTTP server on unix socket instead of address > and port (int evhttp_bind_socket(struct evhttp *http, const char *address, > u_short port) ). Make sure you're using the latest 2.0.x-rc, and try evhttp_accept_socket or evhttp_bind_listener ? -- -- Nick *********************************************************************** To unsubscribe, send an e-mail to majordomo <at> freehaven.net with unsubscribe libevent-users in the body.
RSS Feed20 | |
|---|---|
27 | |
49 | |
46 | |
65 | |
39 | |
40 | |
42 | |
58 | |
58 | |
26 | |
61 | |
46 | |
66 | |
47 | |
58 | |
48 | |
40 | |
35 | |
20 | |
40 | |
88 | |
59 | |
66 | |
78 | |
46 | |
34 | |
62 | |
44 | |
71 | |
110 | |
72 | |
75 | |
50 | |
59 | |
33 | |
30 | |
46 | |
76 | |
38 | |
56 | |
46 | |
44 | |
58 | |
31 | |
17 | |
41 | |
41 | |
59 | |
58 | |
46 | |
32 | |
35 | |
19 | |
19 | |
10 | |
20 | |
25 | |
30 | |
60 | |
46 | |
37 | |
26 | |
15 |
