On Thu, Jan 24, 2002 at 11:12:42AM -0500, alex j avriette wrote:
> 
> I wanted to pop into this conversation briefly... I wrote a napster 
> server using POE and a module I called POE::Filter::LittleEndian (before 
> I had really tinkered with PoCo::IRC). I believe most of that code is 
> available on http://envy.posixnap.net/~alex/perlcode/, but I could be 
> mistaken (theres some odd proxy/firewall issue with that site)... 
> Unfortunately it really was only able to handle about 250 connections 
> before it became so slow as to become useless.

perlserver.pl is 403 forbidden.  Have you tried increasing the SysRW
maximum read/write size?  POE 0.17's default block size is 512 bytes,
so a 10MB file would require at least 20480 events be processed.  POE
0.18 defaults to 4096 byte blocks, so the same file would be streamed
in at least 2560 events.  With this code, you can do it in only 640
events, assuming the other end can keep up with you:

  Driver => POE::Driver::SysRW->new( BlockSize => 16384 );

The event counts will be higher if the other side can't keep up.

> So while I admire the project (and I've thought of writing an IRC server 
> myself, as I like bahamut but dislike not being able to hack on it), I'd 
> like to inject a little caution ... useful as Services, probably. Not 
> particularly useful as a drop-in for an ircd however. This strikes me as 
> unfortunate.

It's possible to write POE servers at three levels.  Each successively
higher level trades away some control and performance for convenience.

At the lowest level, there's POE::Kernel's select_foo() methods and
raw socket calls.  The select_foo() methods simply invoke your event
handlers when a filehandle becomes ready; the reading and writing is
left as an exercise for the programmer.

  $kernel->select_read( HANDLE => EVENT );
  $kernel->select_write( HANDLE => EVENT );

The POE::Wheel::Foo classes are implemented in terms of select_foo().
They have evolved over time to do a lot of things (like flow control),
some of which are probably not necessary in any given program.

Finally there's POE::Component::Server::TCP.  It's implemented in
terms of POE::Wheel::SocketFactory and ReadWrite.  You get virtually
no control over any of the particulars of server I/O, but it lets you
write servers with very little extra code.

I guess my point there is that performance can be claimed back by
moving down to lower-level code.

> I'd love to contribute if I can however.

Publishing your Napster code would help.  There are lots of options if
you want a more direct hand in POE's development...

There's a lot of room for optimizing in the file I/O code, even at its
lowest level.  I recently added some quick hacks for Windows
compatibility, and I'm certain they could be done better.

On a more higher level, there are a lot of half-baked ideas on POE's
web site.  Implementing one of them, or even just commenting on them,
would be a big help.  It's a lot of stuff to think about, and it would
go faster with more brains working on it.  See:

http://poe.perl.org/?POE_RFCs  --  General ideas.
http://poe.perl.org/?POE_RFCs/object_layer  --  Component architecture ideas.

No help is too small.  Thanks!

-- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sf.net

Reply via email to