|
0.0.2
Aug 12, 2005 0:01:13 GMT -5
Post by Jim Brain on Aug 12, 2005 0:01:13 GMT -5
Things changed:
added robust debugging fixed deadlock and race conditions in Chat code added support for logging off (with correct time notations) Database support for non-People Connection areas You can move from area to area via menus You can move to People Connection from other areas
Still to do:
Have not figured out how to get from People Connection to other areas (client sends MXPS005 and expects an ack, but MX isn;t it, and other stuff I tried did not work) Work on supporting more than menus in non PC areas.
|
|
|
0.0.2
Aug 12, 2005 0:55:29 GMT -5
Post by Jim Brain on Aug 12, 2005 0:55:29 GMT -5
I also added an info dialog before the main menu, telling of upcoming or current events.
|
|
|
0.0.2
Aug 12, 2005 12:21:02 GMT -5
Post by Keith Henrickson on Aug 12, 2005 12:21:02 GMT -5
Wow! When you get going, you get GOING! BTW, dunno if you caught it in my command list, but... You can probably save yourself a bit of work with the 'message of the day' thing. Send it using the SM and SE commands (I THINK it's SM for all lines except the last, and SE for the last line). Then when the user hits F5, they go directly to the main menu. You don't have to bother with DO or anything. Saves a packet.
|
|
|
0.0.2
Aug 12, 2005 20:01:33 GMT -5
Post by Jim Brain on Aug 12, 2005 20:01:33 GMT -5
I saw that this morning (I had previously looked over your code, but a lot of just did not make sense until I got farther into the coding here), so I redid it this evening. I also moved it to the MainMenu state (it was getting sent in the Authentication state)
I added the MC reply to MX, and that works, so now I can move between the areas.
I pored over your email and gateway code today. Email is first up. Although long term I want to gateway with SMTP/IMAP, for now, I'm just going to implement a static DB table for emails.
Funny how the dialog and SM/SE does essentially the same thing.
Also found that IG (ignore user) sends the command out, but ignores the user all in the client. It expects an ack (I sent IG, it seems to work). I'm assuming the idea was to stop traffic from that person from being sent, but ignore it if it shows up in the client. IX (de-ignore) works the same.
I also noticed that ignores do not travel from room to room. If you ignore JIM in Lobby, and then move to TEENS, JIM will not be ignored any longer.
Highlight is a client only thing, so that's fine with me.
Although the code works now, I'm still unsure about a few things:
If you try to make a private Lobby, would it have worked? Can you create a new Lobby named LobbyZ if it did not exist? Is it a Lobby, or just a room? DO you put the Post Office/Move to Another QLink area on each menu at the end, or just the root menus? (I see you just did the root menus).
Jim
Jim
|
|
|
0.0.2
Aug 13, 2005 3:21:41 GMT -5
Post by Keith Henrickson on Aug 13, 2005 3:21:41 GMT -5
Yeah, SM/SE is basically a predefined dialog that drops to the main menu. It saves the 'start dialog', 'start dialog confirm', 'close dialog' and 'main menu packets'
You cannot create a private room Lobby, you'd get error 'C3'. "The room is public and cannot be made private"
You can create LobbyZ as public. If the system ever got to that many Lobbys, then you would see people start joining your room. You ought to be able to create it as private, too, and if the system starts dropping people into it, oh well. This is how other rooms are handled. If you have the private room, "XXX", then someone joins it, they join it. Doesnt' matter which command they used. On the other hand, if the room is public, attempting to join it privately will result in error 'C3', warning the user that they would be in public, not private.
I am sure the 'change areas' was ONLY at the root menus. Post office, I'm not so sure about. It certainly was not on EVERY menu.
|
|
|
0.0.2
Aug 13, 2005 4:19:24 GMT -5
Post by Jim Brain on Aug 13, 2005 4:19:24 GMT -5
So, there could only be one instance of a named room. It was either public or private.
And, in other news, I implemented email, which works fine, and I found a new command not in you list: EQ. If you read an email, hit F7, select answer, and then hit F7 to cancel, it sends that. And, the correct response is a bare ack $24, which means that $24 is not just an ack for Resets, but for normal acks as well. I also needed to use ACK to respond to the email text coming in. After the email comes into the server, the client expects and ACK.
There is an issue I can't seem to find a solution for in your qlinkold code. When you read an email, hit F7 to answer, the recipient coming back is wrong.
I think I will copy your idea of sending email to a DB table, and then piping POP3 into the DB instead of patching the server to SMTP/POP directly.
Still have OLMs and gateways to add, and then I think I'll be as complete as qlinkold. You have your Puzzler or other stuff ready to show anyone?
|
|
|
0.0.2
Aug 13, 2005 13:41:55 GMT -5
Post by Keith Henrickson on Aug 13, 2005 13:41:55 GMT -5
Hmm, you shouldn't have to send layer 2 packets in direct response to layer three packets. I'll have to explore that someday. I did just find a text file of some puzzler and maybe superq commands. They are FAR from complete. I never DID figure out how to put a menu up in SuperQ. It's not a fixed menu as in PC, and must be sent down. I could get raw text, but never menus. You could load puzzler anyway by breifly dropping the user in a fake room and then forcing them to puzzler. I never wrote any server code for this, just wrote a program to let me type commands at it. I should play with Puzzler again. It was the only game I bothered spending time to play. Club Caribe was just WAY too disk based to spend my 1 hr a month loading.
|
|
|
0.0.2
Aug 13, 2005 14:10:10 GMT -5
Post by Jim Brain on Aug 13, 2005 14:10:10 GMT -5
I think what really happens is the system receives the incoming packet, processes it, but also notes an unacked packet. When no response packet erases that, and a timer pops, the Layer 2 subsystem dos a bare ack, as Randell noted elsewhere in here. Of course, I have yet to implement the sliding windows, so my layer 2 would not know this. Jim
|
|
|
0.0.2
Aug 15, 2005 0:38:03 GMT -5
Post by Jim Brain on Aug 15, 2005 0:38:03 GMT -5
I determined the issue with the recipient coming back, it has to be in the email message.
However, I implemented the code as per qlinkold, and now all my emails have "Please type your message now..." as line 2. Was that common in QLink days, or did that line have dates or a subject in it?
As for the bare ACK, I think I know how it works now. When the client sliding window is full, it sends a $21, and I have to base ACK that. So, that may be how you do it.
Email is implemented, though I don't like one aspect of it.
I have no way of knowing if the user read the email. But, I have to delete it after I send it to the user. What if there is a power loss after I send it, but before they read it? Or, the packets get screwed up? Seems a bit lossy to me.
Jim
|
|
|
0.0.2
Aug 15, 2005 1:05:23 GMT -5
Post by Keith Henrickson on Aug 15, 2005 1:05:23 GMT -5
The client should start composing lines like this: www.bytemeelectronics.com:81/Quantum/q-link/Images/qlink-peopleconnection-sendmail.jpgMy server probably gets it wrong. I rarely sent email, so I had to guess what it looked like. The client DOES send back all the lines, including the ones the server sends to it, and thus it is possible for a hacker program to modify those lines in client memory and spoof email. You may wish to fix this in your server by ignoring the first two lines and replacing them with valid server generated text. If packets are corrupted or misplaced, but the connection is alive, layer 2 will retransmit. You need do nothing special. You cannot do anything about power failure. If the client looses power, yes, they will loose the email. With a HACK, you could get around the connection dropping. Rather than deleting the email when you send the final packet, delete it when that packet is ACKed by the client. Either through the second sequence number, or an explicit ACK. This is really VERY BAD, as layer 3 should not have any knowledge of what layer 2 has done, and so on and so forth. But if you implement it generically, perhaps some type of callback function, you might make the interface graceful enough to be worth it.
|
|
|
0.0.2
Aug 16, 2005 17:05:24 GMT -5
Post by Jim Brain on Aug 16, 2005 17:05:24 GMT -5
What about this? What about leaving the email as read but not deleted until I get a new incoming command. At that point, I would know the email has been received and read... That would only require Layer 3 stuff.
Jim
|
|
|
0.0.2
Aug 16, 2005 17:07:48 GMT -5
Post by Jim Brain on Aug 16, 2005 17:07:48 GMT -5
And yes, once I sent this email, I checked Keith's site and found the correct Line 2, so I implemented that. Much better (I switched it to 4 digit dates, a sign of the times). His site is down, though, or was, so I had to load the pic from cache.
FOr now, I'm "bug for bug" compatible with the original per emails, but I like your idea of rewriting Line1,2 when receiving the email.
|
|
|
0.0.2
Aug 16, 2005 17:32:02 GMT -5
Post by Keith Henrickson on Aug 16, 2005 17:32:02 GMT -5
What about this? What about leaving the email as read but not deleted until I get a new incoming command. At that point, I would know the email has been received and read... That would only require Layer 3 stuff. Jim Now I'm the one feeling not worthy! VERY nice idea!
|
|