Antique DikuMUD I3 code

[quixadhal]

So, partly for amusement and partly because I'm tired of the stupid IMC color codes screwing up URL's, I decided to try and revive the old I3 code for Smaug that worked years ago, but was dropped when MudBytes picked up the IMC2 torch.

It appears to connect and talk to *i4 ok.  I can connect and get a mudlist with no problems.  However, I don't ever get any channel listings.

Looking at the spec, when you send the startup-req-3 packet, the server *might* deign to send you a chanlist-reply packet, telling you about channels you didn't know about.

So, I predict one of two possible reasons for this error.  One -- *i4 never sent me a chanlist-reply packet, and so either I'm in error with the startup packet, or I'm just unworthy.  Two -- *i4 did send me a packet with the entire channel listing, and it managed to overflow the DikuMUD "MAX_STRING_LENGTH" buffer limit, which silently dropped it on the floor.

Cratylus?  Any chance you could check on your end to see if you sent me a gigantic packet that I dropped?  I'll try to paw through the socket code on this end and add some more debugging code.

As usual, no hurry, and thanks!

[quixadhal]

ADDENDUM:  Yep, just added some debugging code... There be WHALES here!

: I3: Attempting connect to 204.209.44.3 on port 8080
 : I3: Connected to Intermud-3 router *i4
 : I3: Intermud-3 Network initialized.
 : I3: Sending startup_packet to *i4
 : I3: String overflow in I3 socket read!
 : I3: ({({"*i4","204.209.44.3 8080",}),})
 : I3: Received startup_reply from *i4
 : I3: Intermud-3 Network connection complete.
 : I3: String overflow in I3 socket read!
 : I3: String overflow in I3 socket read!
 : I3: String overflow in I3 socket read!
 : I3: I3_process_chanlist_reply: Got chanlist-reply packet!

Most unfortunate.
I can easily up the buffer size for the I3 module, but I then have to muck about to make sure nothing in that code ever tries to print directly to anything in the mud itself, since raising the size of every large array isn't something I really want to do.

However, it does appear that SOME of the packets made it through, as I now have SOME channels listed.  Very odd.  Me no like things that work without me changing anything.

[quixadhal]

Another update:

In our last session, we appeared to have at least partial success, in that I managed to obtain a channel listing (at least partial) and subscribed to some number of channels.  So, today, I reconnected and found to my surprise that the chanlist command only showed me the channels I had set up LOCAL channels for.

The way it's supposed to work (this is the client code, not the I3 spec!) is "i3chanlist" shows you the channels your server admin has setup locally, and which ones you are listening to.  "i3chanlist all" shows you ALL the channels your server knows about on I3.  The distinction is important, because for anyone to actually listen to a channel, it has to be setup locally, and to set one up locally, you have to be able to see them.

Poking through the logs, I see that I never got a "chanlist-reply" packet this session.  Now, to be fair, I *think* the intent behind the I3 spec (and thus *i4's implementation) is to save a "chanlist-id" along with your password and mudname.  Any time anyone creates/destroys/renames/etc any channel on I3, the server will presumably generate a new "chanlist-id" and send out the changes to the chanlist with this new id.  If a client connects using the current chanlist-id, no listing is actually sent since presumably the client already got it and it hasn't changed.

The problem then, lies on my stupid Diku client's code NOT saving the full and complete channel listing.  Since it's based off the IMC2 code, that's not a shocker as IMC2 doesn't allow for dynamic channel creation, nor does it have very many channels.

It's a bit of an annoyance though, because there isn't any way to force a resend of the chanlist data, other than to disconnect, fudge your chanlist-id to some invalid number, and reconnect -- hoping for the best.

Any suggestions are welcome, although I'll probably have to just modify the code to save ALL channels with empty strings for the "local" channels of ones not setup.

Mostly, I wanted to describe what was going on, so if it sounds hokey, Crat can look into it.  If it sounds like that's what should be happening, it's a breadcrumb trail for others going this way.