Re: POE::Component::Server::IRC
On Thu, Jan 24, 2002 at 12:11:44PM -0600, Bob Maccione wrote: > well, we're finally blessed with decent hardware (which means a 16 processor > E10k with 12G of memory) so yeah, 6M isn't a big deal. > > However, I'm not sure if I understand your wording, if I get a 100byte > message and have the BlockSize set to 30k, wouldn't I be passing around a > 100byte (+some overhead) message? If nothing else I'm interesting in a > buffer pool (since in my app at least not all client connections would be > active at one time). Yes, you would. I'm assuming programs that stream a lot of data, or at least send transactions larger than the default block size. Actually, if the program can't keep up with the sender, multiple messages may pile up in the system's socket buffer. In that case, the larger sysread block size will slurp up several at once (up to, say, 300, if your block size is 3 and the messages are just 100 bytes). Filter buffering will also chew up memory, up to the size of a complete message plus any overrun into the next. -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sf.net
Re: POE::Component::Server::IRC (and PoCo::FTP and other goodies)
On Thu, Jan 24, 2002 at 12:47:52PM -0500, alex j avriette wrote: > > On Thursday, January 24, 2002, at 11:52 AM, Rocco Caputo wrote: > > > 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 > > Okay, I'll have a looksee. Two things on my list of "code that needs to > be written": > > A. Streaming server for MP3/Ogg data This one I can help a little with. Here's a simple streaming web server adapted from a sample written by Arthur Bergman. http://poe.perl.org/?POE_Cookbook/Web_Stream_Server That reminds me: Another way to help is to suggest or write articles for the cookbook and/or FAQ. A lot of people learn better by example. > A note about napster servers. They function almost exactly like IRC > servers. They are a chat medium, with an improvised sort of CTCP for > sharing files. The server itself shares no files. Increasing the SysRW block size may not help as much as I originally thought. I had the strange idea that your server was streaming large files. -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sf.net
Re: POE::Component::Server::IRC (and PoCo::FTP and other goodies)
On Thu, Jan 24, 2002 at 12:47:52PM -0500, alex j avriette wrote: > course wrote the LittleEndian filter, and the napster server. I am very > impressed with it and want to contribute however I can. I suspect > finishing off PoCo::FTP would be useful to the project, but I'd have to > reach sungo to do that I suspect. Is sungo on list? I don't know if sungo did something, but you could try a module i wrote: http://sourceforge.net/projects/poeftp. It works well so far. Data connections are missing and the API is quite raw atm but i like the cmd queue stuff somehow, and it works :) Finishing it should not be too much work. It mostly depends on the chosen interface, passing data packets as events is easy, interoperating with client session wheels isn't. I havent worked on it since I had no time and there were no urgent need. Additionaly I wanted to make it the test case for a coloured petri net implementation. I read about these some months ago and they should really help. Implementing it is not easy, the original implementation uses Standard ML and strong type checking and binding to tokens based on their values. A lot of the power results from that, yet I don't really know how to do it in Perl. Anyway, it could make POE programming a lot easier, concurrency related behaviour is much easier to get as a petri net. I hope that I can come up with something in the next 1 or 2 months, depends on the time and brain I got :) For example, it could remove all the ugly cmd chain/queue handling in the FTP module, all the internal states, race condition work arounds, ... torvald
Re: POE::Component::Server::IRC (and PoCo::FTP and other goodies)
On (01/24/02 12:47), alex j avriette wrote: > finishing off PoCo::FTP would be useful to the project, but I'd have to > reach sungo to do that I suspect. Is sungo on list? but of course i am. i am not pursuing that poco anymore. my last employer pulled funding of that project and i dont work that employer anymore. it was one of those things where i needed it for work. but now i dont. have at. poco::Ftp is one of those oft talked about never done kinda things. here's to hoping you actually finish it :) > B. PoCo::FTP (you have no idea how much I despise Net::FTP) when the revolution comes, the Net:: tree is first up against the wall. /me shivers. m.
Re: POE::Component::Server::IRC
On Thursday 24 January 2002 12:58 pm, you wrote:
> Speaking of memory, has anyone done an analysis of various version of POE
> and perl, to see how much memory each one of these configurations use? I
> would like to use POE on an embedded device which has limited memory, and
> no swap space. If there is a particular combination of POE/perl that is
> low on memory usage, I'll be the first one to jump on it. :)
POE seems memory heavy. You might want to play with this:
(It needs the GTop.pm module with interfaces with Gnome's GTop application,
much to my suprise, so you need to fetch that particular application and it's
development package, or the whole source tarball, and (compile) install it,
first.)
#!/usr/bin/perl -w
use lib '/home/jasonb/local/lib/perl/5.6.1';
use lib '/home/jasonb/src/webzeus/webzeus/src';
use GTop ();
# Shamelessly ripped from
# http://perl.apache.org/guide/performance.html
# by Stas Bekman
# Thanks Stas!!
my $gtop = GTop->new;
my $before = $gtop->proc_mem($$)->size;
for (@ARGV) {
if (eval "require $_") {
eval {
$_->import;
};
}
else {
eval $_;
die $@ if $@;
}
}
my $after = $gtop->proc_mem($$)->size;
printf "@ARGV added %s\n", GTop::size_string($after - $before);
$./perlboat.pl 'use POE qw(Wheel::SocketFactory Wheel::ReadWrite)';
use POE qw(Wheel::SocketFactory Wheel::ReadWrite) added 2.3M
$
$./perlboat.pl 'use POE';
use POE added 1.9M
$
Someone who understands what's going on better than I might be able to
interpret those numbers for you beyond the obvious "Wow, that's big!"
> -a
>
> At 12:51 PM 1/24/2002 -0500, you wrote:
> >On Thu, Jan 24, 2002 at 11:10:49AM -0600, Bob Maccione wrote:
> > > I've been playing with the BlockSize on my app (that's not quite done
> > > yet) and am wondering what the downside of having a larger BlockSize
> > > is? If I know that my max message size will be 30k what is wrong with
> > > setting the BlockSize to 30k (now I understand that you don't want to
> > > set it to really really large sizes but where are the tradeoffs?
> >
> >It eats up more memory. If you have 200 clients each sending 30KB
> >blocks, it could potentially chew up 6MB of memory just to buffer
> >them. Come to think of it, that's not a whole lot these days.
> >
> >I imagine at some point the amount of time it takes to move those
> >blocks around breaks even with the speed gain you get from having
> >them. I can't begin to guess where that occurs.
> >
> >-- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sf.net
Re: POE::Component::Server::IRC
On Thu, 24 Jan 2002 09:58:31 -0800 "Andrew A. Chen" wrote: +-- | Speaking of memory, has anyone done an analysis of various version of POE | and perl, to see how much memory each one of these configurations use? I | would like to use POE on an embedded device which has limited memory, and | no swap space. If there is a particular combination of POE/perl that is | low on memory usage, I'll be the first one to jump on it. :) +-- Here is one data point: FreeBSD 4.5-RC ps -auxww | egrep 'USER|perl' USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND cfedde 99628 0.0 3.2 4636 3956 p3 I11:14AM 0:00.97 perl -MPOE -e sleep 600 cfedde 99636 0.0 1.1 2108 1428 p3 I11:16AM 0:00.01 perl -e sleep 600 +-- | | At 12:51 PM 1/24/2002 -0500, you wrote: | >On Thu, Jan 24, 2002 at 11:10:49AM -0600, Bob Maccione wrote: | > > I've been playing with the BlockSize on my app (that's not quite done ye t) | > > and am wondering what the downside of having a larger BlockSize is? If I | > > know that my max message size will be 30k what is wrong with setting the | > > BlockSize to 30k (now I understand that you don't want to set it to real ly | > > really large sizes but where are the tradeoffs? | > | >It eats up more memory. If you have 200 clients each sending 30KB | >blocks, it could potentially chew up 6MB of memory just to buffer | >them. Come to think of it, that's not a whole lot these days. | > | >I imagine at some point the amount of time it takes to move those | >blocks around breaks even with the speed gain you get from having | >them. I can't begin to guess where that occurs. | > | >-- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sf.net | +-- --
RE: POE::Component::Server::IRC
well, we're finally blessed with decent hardware (which means a 16 processor E10k with 12G of memory) so yeah, 6M isn't a big deal. However, I'm not sure if I understand your wording, if I get a 100byte message and have the BlockSize set to 30k, wouldn't I be passing around a 100byte (+some overhead) message? If nothing else I'm interesting in a buffer pool (since in my app at least not all client connections would be active at one time). > -Original Message- > From: "Rocco Caputo" <[EMAIL PROTECTED]>@INTERNET@HHC > Sent: Thursday, January 24, 2002 9:52 AM > To: [EMAIL PROTECTED] > Subject: Re: POE::Component::Server::IRC > > <<...>> > On Thu, Jan 24, 2002 at 11:10:49AM -0600, Bob Maccione wrote: > > I've been playing with the BlockSize on my app (that's not quite done > yet) > > and am wondering what the downside of having a larger BlockSize is? If > I > > know that my max message size will be 30k what is wrong with setting the > > BlockSize to 30k (now I understand that you don't want to set it to > really > > really large sizes but where are the tradeoffs? > > It eats up more memory. If you have 200 clients each sending 30KB > blocks, it could potentially chew up 6MB of memory just to buffer > them. Come to think of it, that's not a whole lot these days. > > I imagine at some point the amount of time it takes to move those > blocks around breaks even with the speed gain you get from having > them. I can't begin to guess where that occurs. > > -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sf.net >
Re: POE::Component::Server::IRC
Speaking of memory, has anyone done an analysis of various version of POE and perl, to see how much memory each one of these configurations use? I would like to use POE on an embedded device which has limited memory, and no swap space. If there is a particular combination of POE/perl that is low on memory usage, I'll be the first one to jump on it. :) -a At 12:51 PM 1/24/2002 -0500, you wrote: >On Thu, Jan 24, 2002 at 11:10:49AM -0600, Bob Maccione wrote: > > I've been playing with the BlockSize on my app (that's not quite done yet) > > and am wondering what the downside of having a larger BlockSize is? If I > > know that my max message size will be 30k what is wrong with setting the > > BlockSize to 30k (now I understand that you don't want to set it to really > > really large sizes but where are the tradeoffs? > >It eats up more memory. If you have 200 clients each sending 30KB >blocks, it could potentially chew up 6MB of memory just to buffer >them. Come to think of it, that's not a whole lot these days. > >I imagine at some point the amount of time it takes to move those >blocks around breaks even with the speed gain you get from having >them. I can't begin to guess where that occurs. > >-- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sf.net
Re: POE::Component::Server::IRC
On Thu, Jan 24, 2002 at 11:10:49AM -0600, Bob Maccione wrote: > I've been playing with the BlockSize on my app (that's not quite done yet) > and am wondering what the downside of having a larger BlockSize is? If I > know that my max message size will be 30k what is wrong with setting the > BlockSize to 30k (now I understand that you don't want to set it to really > really large sizes but where are the tradeoffs? It eats up more memory. If you have 200 clients each sending 30KB blocks, it could potentially chew up 6MB of memory just to buffer them. Come to think of it, that's not a whole lot these days. I imagine at some point the amount of time it takes to move those blocks around breaks even with the speed gain you get from having them. I can't begin to guess where that occurs. -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sf.net
Re: POE::Component::Server::IRC (and PoCo::FTP and other goodies)
On Thursday, January 24, 2002, at 11:52 AM, Rocco Caputo wrote: > perlserver.pl is 403 forbidden. Have you tried increasing the SysRW Oops, sorry, that machine was recently upgraded and im afraid a complete mirror of its previous configuration was not accomplished. http://envy.posixnap.net/~alex/perlcode/perlserver/perlserver.pl.txt is the code for the server, and its now available. I could *swear* I previously sent this code to the list, but it was in that transitory period between two servers, so it may have never gotten out at all. so the modules necessary for the server are there as well as the server itself. it was mostly just a proof of concept. i got discouraged when it became slow and just chalked it up to perl not being able to handle it. If there's something I'm doing thats deliberately obtuse, let me know and I'll dig right in again. > It's possible to write POE servers at three levels. Each successively > higher level trades away some control and performance for convenience. To be honest, I havent really gone over the POE documentation extensively, and the napster server was my first project. I saw PoCo::FTP and decided I wanted to hack on that, but havent had time to make it useful. >> 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... I am a POE zealot already. It is far superior to any of the other network interfaces (yes I am aware that POE is not a network interface, but thats what it means to me) that perl has. Ive used PoCo::IRC, of course wrote the LittleEndian filter, and the napster server. I am very impressed with it and want to contribute however I can. I suspect finishing off PoCo::FTP would be useful to the project, but I'd have to reach sungo to do that I suspect. Is sungo on list? > 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 Okay, I'll have a looksee. Two things on my list of "code that needs to be written": A. Streaming server for MP3/Ogg data B. PoCo::FTP (you have no idea how much I despise Net::FTP) C. (waaay down on the priority list) The Napster server. I'd like to talk to LDS about this as well, he wrote a napster server using IO::Socket, as well as a client module (MP3::Napster), which might be better off being POE. Oh, since I've forgotten to add this above... A note about napster servers. They function almost exactly like IRC servers. They are a chat medium, with an improvised sort of CTCP for sharing files. The server itself shares no files. > No help is too small. Thanks! Hey, I'm happy to contribute what I can. I really like POE and perl. :-) alex
RE: POE::Component::Server::IRC
I've been playing with the BlockSize on my app (that's not quite done yet) and am wondering what the downside of having a larger BlockSize is? If I know that my max message size will be 30k what is wrong with setting the BlockSize to 30k (now I understand that you don't want to set it to really really large sizes but where are the tradeoffs? thx, bobm > -Original Message- > From: "Rocco Caputo" <[EMAIL PROTECTED]>@INTERNET@HHC > Sent: Thursday, January 24, 2002 8:53 AM > To: [EMAIL PROTECTED] > Subject: Re: POE::Component::Server::IRC > > <<...>> > 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 >
Re: POE::Component::Server::IRC
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
Re: POE::Component::Server::IRC
On Thu, Jan 24, 2002 at 11:12:42AM -0500, alex j avriette wrote: > > On Thursday, January 24, 2002, at 09:29 AM, [EMAIL PROTECTED] > wrote: > > > On Wed, Jan 23, 2002 at 04:11:28PM -0600, [EMAIL PROTECTED] wrote: > >> I made a hint on the POE::Component list on the wiki that I am working > >> on the P::C::S::I module, but I forgot to check the list to see if > >> anyone else is working on it. > >> > >> Let me know if you are, otherwise I'm gonna continue writing it. > > 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. The machine in question > was able to run OpenNap (the C alternative) at greater than 3300 users > (where it eventually filled up 512mb of ram, not the cpu). Was there a specific bottleneck, or could you summarize the performance problems? I haven't looked at the code yet. But is there something specific that could be done or that stands out, apart from the fact that it's c vs. perl as well ? Did the napster server have to server files or just reply to queries ? It might be useful to work on that a bit, because most POE applications do not cause so much load. So it would be a good example to study how to improve performance. Torvald
Re: POE::Component::Server::IRC
On Thursday, January 24, 2002, at 09:29 AM, [EMAIL PROTECTED] wrote: > On Wed, Jan 23, 2002 at 04:11:28PM -0600, [EMAIL PROTECTED] wrote: >> I made a hint on the POE::Component list on the wiki that I am working >> on the P::C::S::I module, but I forgot to check the list to see if >> anyone else is working on it. >> >> Let me know if you are, otherwise I'm gonna continue writing it. 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. The machine in question was able to run OpenNap (the C alternative) at greater than 3300 users (where it eventually filled up 512mb of ram, not the cpu). 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. I'd love to contribute if I can however. Alex
Re: POE::Component::Server::IRC
On Wed, Jan 23, 2002 at 04:11:28PM -0600, [EMAIL PROTECTED] wrote: > I made a hint on the POE::Component list on the wiki that I am working > on the P::C::S::I module, but I forgot to check the list to see if > anyone else is working on it. > > Let me know if you are, otherwise I'm gonna continue writing it. If you (or other people) want to have encrypted IRC check out www.silcnet.org please. Unlike SSL'ed IRC it gives you real client to client encryption and some other features. It is not widely used though, but the architecture is good and it is very IRC-like. The resulting module would probably be a wrapper around the existing silcnet client libraries. There are a lot of IRC servers and clients available already, silcnet would be new ground to work on :) Torvald
Re: POE::Component::Server::IRC
On Wed, Jan 23, 2002 at 04:30:11PM -0800, Dennis Taylor wrote: > On Wed, Jan 23, 2002 at 05:12:34PM -0500, Casey West wrote: > > > This makes me want to write a minimal client program using the curses > > libraries. It was pretty easy to write pong, how hard could this be? > > :-) > > I seem to recall that someone already wrote a console-based IRC > client using POE and POE::Component::IRC. I think it was dngor, in fact, > who showed it to me. Who was working on that, anyways? A guy on efnet who goes by the nick lunartear. I'm helping, but we're really both bashing our brains out on a Curses problem. Updating a lot of text at once (scrolling back and forth, for example) corrupts the display. Other than that, it's mostly functional. I've heard rumors that fbsd's ncurses isn't all that hot, so maybe it's not the Perl code doing it. Other areas we're looking at are terminal flow control (it happens in xterm but not on the text console) and termcap problems (cons25 vs. xterm-color). > > Also, I'd like to add encryption to it, and it would be cool to have > > an encryption based server that I can trust. > > Try ssh + ytalk. :-) Heh heh heh! -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sf.net
Re: POE::Component::Server::IRC
On Wed, Jan 23, 2002 at 05:12:34PM -0500, Casey West wrote: > This makes me want to write a minimal client program using the curses > libraries. It was pretty easy to write pong, how hard could this be? > :-) I seem to recall that someone already wrote a console-based IRC client using POE and POE::Component::IRC. I think it was dngor, in fact, who showed it to me. Who was working on that, anyways? > Also, I'd like to add encryption to it, and it would be cool to have > an encryption based server that I can trust. Try ssh + ytalk. :-) _ Dennis Taylor "Anyone whose days are all the same and free from [EMAIL PROTECTED]want inhabits eternity of a sort." - Peter Hoeg _ PGP Fingerprint: E8D6 9670 4FBD EEC3 6C6B 810B 2B30 E529 51BD 7B90
Re: POE::Component::Server::IRC
On Wed, 2002-01-23 at 22:11, [EMAIL PROTECTED] wrote: > I made a hint on the POE::Component list on the wiki that I am working > on the P::C::S::I module, but I forgot to check the list to see if > anyone else is working on it. > > Let me know if you are, otherwise I'm gonna continue writing it. > Keep us informed, this is something that Ive wanted to see for a long time so I can quickly knock up services daemons in POE (things like custom nickservs etc). Good work :) -Mark -- Mark Cheverton aka ennuihttp://morat.net/ Morat Games IM: [EMAIL PROTECTED] --+++ Less Lag More Frag +++-- signature.asc Description: This is a digitally signed message part
Re: POE::Component::Server::IRC
On (01/23/02 17:12), Casey West wrote: > This makes me want to write a minimal client program using the curses > libraries. It was pretty easy to write pong, how hard could this be? > :-) > > Also, I'd like to add encryption to it, and it would be cool to have > an encryption based server that I can trust. hang tight a little while longer and i'll finish sslsocketfactory up and you can just drop it in with no code changes. :) m.
Re: POE::Component::Server::IRC
On Wed, Jan 23, 2002 at 04:11:28PM -0600, [EMAIL PROTECTED] wrote: : :I made a hint on the POE::Component list on the wiki that I am working :on the P::C::S::I module, but I forgot to check the list to see if :anyone else is working on it. This makes me want to write a minimal client program using the curses libraries. It was pretty easy to write pong, how hard could this be? :-) Also, I'd like to add encryption to it, and it would be cool to have an encryption based server that I can trust. Plus, why not have it all in POE? Casey West -- Shooting yourself in the foot with Algol You shoot yourself in the foot with a musket. The musket is aesthetically fascinating and the wound baffles the adolescent medic in the emergency room.
POE::Component::Server::IRC
I made a hint on the POE::Component list on the wiki that I am working on the P::C::S::I module, but I forgot to check the list to see if anyone else is working on it. Let me know if you are, otherwise I'm gonna continue writing it. Thanks --hachi
