deprecating crash

jeffohrt · Newbie Joined: 08 May 2006 Posts: 17

I've got a mud written with POE - the cookbook version of a tcp server ... all the heavy lifting is done by a RiveScript brain ...

When I tried to use it at school with my students the true headaches began as it got repeatedly trashed by the anti-gaming software ... blocking cookies, java and flash, dynamic IP's ... all sorts of evil ...

After months of hacking and patching ... and grafting an ikc server on to it as a fastCGI mimic - instead of a typical cgi style interface I got it working again ... but the code looks like a hair cut a 3yr old would give themself ...

so I took the time to start learning how to write modules ... neatened up everything ... but I've run into a problem ...

The IKC module - POE::Component::IKC::Server - has a deprecated constructor ... in the spaghetti-o code that works, perl spits out a warning and keeps going ... in the module version perl spits out the same warning and the script crashes ...

this is the warning I get from the module version that crashes ...

Cer · Posted: Wed Jul 05, 2006 10:39 pm Post subject:

It looks like it wants POE::Session to be created with create() rather than new(). So searching the module for "POE::Session" to find where it was constructed and changing the method name from "new" to "create" should do it.

jeffohrt · Newbie Joined: 08 May 2006 Posts: 17

eric256 · Posted: Thu Jul 06, 2006 7:49 pm Post subject:

Perhaps we could go the other way around the problem? What exactly was using IKC solving and why do you think you need FastCGI?

There might be a simpler alternative Wink

jeffohrt · Newbie Joined: 08 May 2006 Posts: 17

All the objects that a user interacts with in a mud are stored in a single multilevel hash ... that is periodically written to disk as a backup ... I'm using the module Tie::TwoLevelHash ... so the hash is manipulated normally but the data actually resides on the harddrive not in memory ... access is confined to that process - just like a normal hash (it's a trade-off - sacrifice a little CPU - gain alot of RAM) ... the problem being it's a hash in a persistent perl process (the POE TCP server) ... which makes it inaccessable to external processes like CGI scripts ...

The school I work at in Korea uses anti-gaming software that trashes every aspect of my script ... no java, no flash, can't install alternate clients, no cookies, dynamic IP's and who knows what else ... a cgi client works if I store session ID's as hidden fields in a form ... but that sticks me with using a cgi client that can access variables in another perl process ...

This is exactly what an IKC server does ... it's a doorway between seperate perl processes ... so a CGI client (form) collects the info ... pipes it into the TCP server process thru the IKC server ... subroutines, modules and objects must already be loaded / defined (requirement of IKC - hence the fastCGI mimic) - they process the info just as if it came thru a TCP client - and the response page is written ... piped back out thru the IKC server to the original CGI script ...

One option I am considering ... that circumvents an IKC solution ... rewriting the script to read and write each object as a flat file instead of a hash entry ...

I've reviewed probably a dozen different perl muds and moos ... none do it that way ... no mud I've ever read about does it that way ... I'm assuming there's a reason ... sounds pretty CPU heavy ...

I'll try it ... I have a POE script that connects 250 simple mudbots to a mud ... to stress it ... and see what happens to CPU usage ...

There's one other element confounding this project ... I'm in windows ... which means ActivePerl and PPM ... so I am forced to use outdated versions of POE and related modules ... the newer ones won't install ...

POE is currently 0.35 ... I'm stuck at 0.29 ... but it works ...

eric256 · Posted: Mon Jul 10, 2006 2:56 pm Post subject:

I understand that it might take a significant rewrite, but i'd highly suggest moving to a Database oriented approach. After all databases are written to allow access to the same data from multiple sources. In past MUDS and MOOS i've built the database was pretty straight forward to implement and let me completely ignore any type of locking issues and just let the DB do the right thing.

Keep in mind that there are lots of free open sources Databases you could use.

jeffohrt · Newbie Joined: 08 May 2006 Posts: 17

My remote account does have a MySQL database ... I just haven't used it. I'd like to just bounce a couple assumptions off you and see if I'm on the same page ...

the perl tcp server process will connect to the MySQL database via the DBI module ... and any number of cgi scripts, web servers, ikc servers or whatever else I dream up ... can also connect and disconnect as needed ... reading and writing to the same tables within the database - no file locking or queuing up ?

In my script there are a few subroutines that are only called if the file modification times of different flat files change ... is there a way to check the last modification time of a table in a MySQL database ?

mattaustin · Posted: Thu Jul 13, 2006 6:54 pm Post subject:

MySQL will handle locking or queuing for you, so don't worry about that. For the time part you could insert the current time with each insert into a new column. Then you could have your SELECT use "between" to get all "new" updates.

jeffohrt · Newbie Joined: 08 May 2006 Posts: 17

HELP US, HELP YOU!