Francis Cianfrocca wrote:
> On 8/17/06, William Crawford <wccrawford / gmail.com> wrote:
>>
>>  I hadn't planned to burden this group with all the details, but here we
>> go:
>>
>> The input stream is from a MUD server (text-based multiplayer game)
>> that...
> 
> 
> 
> That's not a simple proxy at all, but a quite complex little 
> application!

Seemed pretty simple to me, hehe.  The first version will simply do the 
login and pass the exact data back and forth.  From there, it's just a 
matter of massaging the stream.

> You'll find you have to deal with a lot of little edges to get this to
> production quality. When your "proxy" runs, will it be running on behalf 
> of
> just one client? Or many clients?

If you have multiple accounts, you can log in multiple times, so 
multiple clients.

Also, eventually, I would like to modify the proxy so that multiple 
clients can log in and get different views of the same stream.  (Yikes!, 
I know.)

> I think EventMachine can be effective for this application, especially 
> since
> it will wrap all the I/O and timing issues for you, but check out the
> development version and look at the Deferrable class. Even though it's 
> not
> released, this code is stable and you will want it to simplify your 
> access
> to the login server.

Actually, my access to the login server is just a couple dozen lines of 
code.  I haven't implemented proper character choosing and stuff, but I 
don't expect to have problems there.

> If you need help designing this, let me know. It would be a pretty
> interesting case study.

Thanks for the offer.  I'm -not- network-programming-inclined...  It has 
always been tough to wrap my head around it, for some reason.  Once I 
get the streams passing info back and forth, I don't expect to have to 
worry about the network stuff until I try to connect multiple clients to 
the same stream.  Heh.  (Oh, and I'll want to use different filtering on 
each output on that stream.  Why think small?)  But that's for later.

> If the two MUD protocols are proprietary, then how do you know what you 
> need
> to know about them? Did you reverse-engineer them?

Simutronics (the owners) contracted with Zuggsoft to make zMud 
compatible, and announced at the same time that they had always intended 
to release the specs for the protocols, but nobody ever found the time. 
Using various sources around the net, I learned the login sequence and 
the 'GSL Codes' are pretty well documented for version 1 of the stream. 
The XML-like version of the stream is pretty obvious since they used tag 
names that actually make sense.  They have publicly (on their forum) 
stated that they intended to release this information so that third 
parties could create clients.

-- 
Posted via http://www.ruby-forum.com/.