libevent: evhttp_handle_request and evhttp_dispatch_callback

Hi all,

I'm looking for a possibility to have only one callback to manage all
those urls:
/static/img/home.jpg
/static/img/banner.jpg
/static/css/style.css

With this sample, I would like to have one callback registered with
"/static/" to manage all of those urls.

Does anyone have an idea ?

Thanks

William

ps:
I've successfully changed evhttp_handle_request wth the following code:
"
void
evhttp_handle_request(struct evhttp_request *req, void *arg)
{
    struct evhttp *http = arg;
    struct evhttp_cb *cb;

    if (req->uri == NULL) {
        evhttp_send_error(req, HTTP_BADREQUEST, "Bad Request");
        return;
    }

Re: Patch: evhttp_connection_set_local_port

On Tue, 2008-11-04 at 08:32 -0800, Niels Provos wrote:
> On Tue, Nov 4, 2008 at 8:24 AM, Richard Jones <rj <at> last.fm> wrote:
> > Not sure I follow - I'm trying to open 1M connections from one machine
> > to another machine. Only 2 machines are involved, and i'm only concerned
> > with the client machine - the server already exists.
> > Given that part of that 4-tuple is a local ip/port pair, I assumed you'd
> > be limited to 2^16 connections from one local ip, because of the limit
> > on port numbers?
> 
> Yes, but using different IP addresses should take care of that - I
> guess I am confused why your OS could not deal with that.   On which
> operating systems did you test this?
> 
> Niels.

Running Debian etch.:
Linux 2.6.18-6-amd64 #1 SMP Tue Aug 19 04:30:56 UTC 2008 x86_64
GNU/Linux

I observed it stopped creating new connections when the local port range
was used up, so assumed that local ports weren't being allocated per-ip.
Admittedly I didn't check what errors were returned. I was checking what
was going on by watching "netstat -n"

RJ

callback firing many (infinite) times for stdin

I'm trying to use libevent for reading data from stdin, and my callback
is being called over and over, even though i'm only sending a couple of
bytes to stdin. 
Here's the jist of it:

Main:
    event_init();
    event_set(&ev, 0 /*stdin*/, EV_READ | EV_PERSIST, read_stdin, NULL);
    event_add(&ev, NULL);
    event_dispatch();

void read_stdin(int fd, short flags, void *data)
{
    int b;
    b = read(fd, buffer, 0);
    fprintf(stderr, "Read %d bytes from %d:", b, fd);
    fprintf(stderr, "'%.*s' ", b, buffer);
    return;
}

Now if i do:

mkfifo fifo
./prog < fifo

and then in another shell:
echo -n "12345" > fifo

i see:
Read 5 bytes from 0:'12345' Read 0 bytes from 0:'' Read 0 bytes from

Re: callback firing many (infinite) times for stdin

On Nov 6, 2008, at 1:30 PM, Richard Jones wrote:

> ......
> i see:
> Read 5 bytes from 0:'12345' Read 0 bytes from 0:'' Read 0 bytes from
> 0:'' Read 0 bytes from 0:'' ...
>
> And the callback keeps firing forever, even tho I'm not sending any  
> more
> data. I can't find anything in the docs about having to acknowledge
> events or dismiss them once fired or anything - what am i missing?
The successful read of zero bytes indicates end-of-stream.

_______________________________________________
Libevent-users mailing list
Libevent-users <at> monkey.org
http://monkeymail.org/mailman/listinfo/libevent-users

Re: callback firing many (infinite) times for stdin

On Thu, 2008-11-06 at 13:37 -0500, Thomas Harning wrote:
> On Nov 6, 2008, at 1:30 PM, Richard Jones wrote:
> 
> > ......
> > i see:
> > Read 5 bytes from 0:'12345' Read 0 bytes from 0:'' Read 0 bytes from
> > 0:'' Read 0 bytes from 0:'' ...
> >
> > And the callback keeps firing forever, even tho I'm not sending any  
> > more
> > data. I can't find anything in the docs about having to acknowledge
> > events or dismiss them once fired or anything - what am i missing?

> The successful read of zero bytes indicates end-of-stream.

Ah, so the < redirection in the shell is sending eof.. If i use:

tail -f fifo | ./prog

i'm able to write multiple times to the fifo, which does what i want as
tail -f doesnt pass on eof.. that's doing what i want now.

thanks,
RJ

Re: callback firing many (infinite) times for stdin

Richard Jones wrote:
> On Thu, 2008-11-06 at 13:37 -0500, Thomas Harning wrote:
>> On Nov 6, 2008, at 1:30 PM, Richard Jones wrote:
>>
>>> ......
>>> i see:
>>> Read 5 bytes from 0:'12345' Read 0 bytes from 0:'' Read 0 bytes from
>>> 0:'' Read 0 bytes from 0:'' ...
>>>
>>> And the callback keeps firing forever, even tho I'm not sending any  
>>> more
>>> data. I can't find anything in the docs about having to acknowledge
>>> events or dismiss them once fired or anything - what am i missing?
> 
>> The successful read of zero bytes indicates end-of-stream.
> 
> Ah, so the < redirection in the shell is sending eof.. If i use:

No, the EOF comes from the `echo` process closing the write end of the fifo/pipe that your shell opened for it.

The < redirection just causes your shell to pass in the read end of the fifo as the stdin fd (and in fact, the
shell 
will block on opening the fifo, and only exec proc once echo opens the fifo for write).

> 
> tail -f fifo | ./prog
> 
> i'm able to write multiple times to the fifo, which does what i want as
> tail -f doesnt pass on eof.. that's doing what i want now.

evhttp and multiple threads, problem with accept()

I read in a previous thread that it's possible to use evhttp across multiple 
threads by creating an event_base per thread, and an evhttp instance per 
thread by calling evhttp_new.

Am I correct in assuming that you create one socket fd and initialize it, then 
pass it to each thread's evhttp via evhttp_accept_socket?  I tried this, then 
put each thread into an event loop by calling event_base_loop, but had the 
following problem:

After a few successful connections, libevent starts handing out warnings about 
failed accepts.  It seems that when a client tries to connect, the event is 
being handled by multiple threads - one is succesfully grabbing the accept() 
and others are bailing out.

I'm most familiar with a single thread handling all the accepts() then handing 
the new fd to a worker thread - but evhttp seems structured to have multiple 
threads calling accept on the same fd.  Is this my problem, or a red herring?

Erik

evhttp and multiple threads, problem with accept()

I read in a previous thread that it's possible to use evhttp across multiple 
threads by creating an event_base per thread, and an evhttp instance per 
thread by calling evhttp_new.

Am I correct in assuming that you create one socket fd and initialize it, then 
pass it to each thread's evhttp via evhttp_accept_socket?  I tried this, then 
put each thread into an event loop by calling event_base_loop, but had the 
following problem:

After a few successful connections, libevent starts handing out warnings about 
failed accepts.  It seems that when a client tries to connect, the event is 
being handled by multiple threads - one is succesfully grabbing the accept() 
and others are bailing out.

I'm most familiar with a single thread handling all the accepts() then handing 
the new fd to a worker thread - but evhttp seems structured to have multiple 
threads calling accept on the same fd.  Is this my problem, or a red herring?

Erik

RE: Patch: evhttp_connection_set_local_port

Thanks, it will certainly help for benchmarking tools and cases where you can't make the server listen on
multiple ports.

Regards,
RJ

-----Original Message-----
From: Niels Provos [mailto:provos <at> gmail.com] 
Sent: 16 November 2008 23:29
To: Jones, Richard W
Cc: libevent-users <at> monkey.org
Subject: Re: [Libevent-users] Patch: evhttp_connection_set_local_port

On Tue, Nov 4, 2008 at 8:40 AM, Richard Jones <rj <at> last.fm> wrote:
> I observed it stopped creating new connections when the local port range
> was used up, so assumed that local ports weren't being allocated per-ip.
> Admittedly I didn't check what errors were returned. I was checking what
> was going on by watching "netstat -n"

That's unfortunate.   In any case, I submitted your fix to trunk and
patches-1.4.   Although, I prefer Alejo Sanchez's suggestion of having
the server listen on multiple ports:

 http://aleccolocco.blogspot.com/2008/11/ephemeral-ports-problem-and-solution.html


Thanks,
Niels.

_______________________________________________

Libevent in Visual Studio 2005

There seems to be initial efforts in 1.4 to build on Windows with Visual
Studio, but the build fails in numerous ways.

The first problem was that most of the 2005 .sln files didn't exist; OK, I
imported the VC6 .dsw workspace, which generated the necessary solution and
project files.  Then I pulled the main .sln and libevent.vcproj files back out
of the tar file, to write over the old and decrepit VC6 versions that don't
include most of the source.

Then I had to move event-config.h from the main source directory into
WIN32-Code/, and comment out _EVENT_HAVE_UINT32_T and _EVENT_HAVE_UINT64_T
from it.

After all that, I can build libevent but none of the test programs, so it's
hard to tell whether it works at all or not.  I'm still plugging away, and I'd
be happy to share the newly-created .sln files, but does anyone have more
positive experiences?  Is there something fundamental I'm missing?
--

-- 
 Matthew Weigel
 hacker
 unique & idempot.ent