|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Archive::Development Archive area for Development's posts that were moved here after an inactivity period of 90 days. |
09-15-2004, 02:09 AM
|
Discordant
|
|
Join Date: Mar 2003
Location: Chambersburg, PA
Posts: 469
|
|
OpenEQ Loginserver
I've been working on the loginserver for OpenEQ recently, most specifically the login-world communication, and I'm a bit confused.
From what I understand, the loginserver sends a user to world request to the worldserver, and the worldserver sends a response back to the LS. After that, I can't quite follow what's done. Can anyone clue me in on what to do next?
The current source is at http://home.archshadow.com/~daeken/ls.py.
Happy Hacking,
Lord Daeken M. BlackBlade
(Cody Brocious)
PS. This loginserver _will not_ work with the official EQ client. It's going to use a custom login protocol over TCP (with SSL for security reasons) rather than the hackish UDP-based protocol EQLive uses. I would rather it stay purely an OpenEQ LS rather than it be used as the base for an EQLive-compatible LS, but since it's under the GPL, you can do what you wish.
|
|
|
|
09-15-2004, 04:14 AM
|
Discordant
|
|
Join Date: Jan 2004
Location: 47
Posts: 339
|
|
afaik, after LS send usertoword to the worldserver, nothing more happens between LS and world.
It only is a premliminary to client contacting the world, with the id and key that were sent in LS -> world usertoworld request
Basically :
1. client contacts LS, to auth
2. LS replies and tells client it's accountid 1234 and private key AbCdE
3. client tells the LS it wants to connect to world N
4. LS tells world N that it will be entered by client, id 1234, key AbCdE
5. client contacts world presenting id 1234 and key AbCdE
|
09-15-2004, 04:19 AM
|
Discordant
|
|
Join Date: Mar 2003
Location: Chambersburg, PA
Posts: 469
|
|
Ah, ok, so my original thought was right. Problem though... I don't see a field for this key in the usertoworld request...
Mind pointing me in the right direction on that part? That should be all I need to finish up the rest of this LS
|
09-15-2004, 04:40 AM
|
Discordant
|
|
Join Date: Jan 2004
Location: 47
Posts: 339
|
|
this is what LS sends to world (ServerOP_LSClientAuth opode) :
Code:
struct ServerLSClientAuth {
int32 lsaccount_id; // ID# in login server's db
char name[30]; // username in login server's db
char key[30]; // the Key the client will present
int8 lsadmin; // login server admin level
sint16 worldadmin; // login's suggested worldadmin level setting for this user, up to the world if they want to obey it
uint32 ip;
};
As for what the server expects from client ... you should find it in the code, somewhere between common/servertalk.h and world/client.cpp, but, oh well it does not matter on LS design, so i didn't really care :(
alos, PCing is a must, unfortunatly :(
|
09-15-2004, 04:45 AM
|
Discordant
|
|
Join Date: Mar 2003
Location: Chambersburg, PA
Posts: 469
|
|
Cool, thank you, I should be able to figure it out now
Hopefully I can get OpenEQ connecting to a world and zone server by next release
I'm currently reverse-engineering the Omens Of War file formats and having a decent degree of success... hoping to render basic geometry today >
|
09-20-2004, 05:38 PM
|
Hill Giant
|
|
Join Date: Sep 2004
Posts: 184
|
|
If it's not compatible with "EQ Live", I'm just wondering how it actually does function. Is it a custom EXE that we run to log in then? Just a bit confused, and a bit anxious too, because I'm looking to be able to host an EQEmu server (5.8 or greater) totally locally without depending on the official EQEmu Login Server.
|
09-20-2004, 10:08 PM
|
Dragon
|
|
Join Date: Jun 2002
Posts: 776
|
|
OpenEQ is a whole new client to run the game on.
|
|
|
|
09-21-2004, 02:50 AM
|
|
Developer
|
|
Join Date: Aug 2003
Posts: 246
|
|
Quote:
Originally Posted by smogo
1. client contacts LS, to auth
2. LS replies and tells client it's accountid 1234 and private key AbCdE
3. client tells the LS it wants to connect to world N
4. LS tells world N that it will be entered by client, id 1234, key AbCdE
5. client contacts world presenting id 1234 and key AbCdE
|
Actually, you missed one step:
3-1. LS sends UserToWorldRequest to world for the user
3-2. World sends UserToWorldResponse indicating a response code (-3 world full, -2 user banned, -1 user suspended, 0 denied, 1 allowed)
3-3. LS responds to the "PlayEverquest" request to the client telling success/failure.
Then if the response back from world is 1 (or it's 0 and the user is an LS admin) then the LS sends UserToWorld to world like you state in 4.
Now, what world will do is check the users status and respond. If the server is locked and the users status is <100 then they get a denied (0) otherwise if their status >=0 they get an allowed.
|
|
|
|
09-21-2004, 02:55 AM
|
|
Developer
|
|
Join Date: Aug 2003
Posts: 246
|
|
Here's a breakdown of what world will respond with:
-3 if world is at max capacity. Not sure were you can set max users, but I assume you can.
-2 if the status on the users account is -2 (banned)
-1 if the status on the users account is -1 (suspended)
0 if the server is locked and the status on the users account is < 100
1 otherwise
|
09-21-2004, 03:13 AM
|
|
Developer
|
|
Join Date: Aug 2003
Posts: 246
|
|
Oh, and with official client once the LS->world handoff completes the client disconnects (sends the disconnect op code) from the login server.
When the client leaves world to return to LS, it logs in again.
|
09-21-2004, 03:35 AM
|
Discordant
|
|
Join Date: Jan 2004
Location: 47
Posts: 339
|
|
hmm, that's a bit too high quality as for the service i've been trying to setup.
Actually i don't handle step 3.3, rather just paste a 1 response packet (always tell world accepts, the client eventually gets kicked or not depending on server allowance)
As for step 3.1, i was putting it in step 4 (so 3.1 and 3.2 would be 4.1 and 4.2)
.. this, unless i'm missing something, and got it working by chance. oops again
Thanks for heads up anyway. This will be added ito the next to next release
|
09-21-2004, 05:49 AM
|
|
Developer
|
|
Join Date: Aug 2003
Posts: 246
|
|
Well, UserToWorldRequest is just asking if this user is allowed to join that world it is not the hand off using the key and such.
The final send from LS to world is actually the ServerOP_LSClientAuth, which is the actual hand off to world.
Step 3.1 is LS sending ServerOP_UsertoWorldReq and waiting for a ServerOP_UsertoWorldResp (step 3.2) from world.
But, the UserToWorldRequest/Respose pair is not required, if you skip it and just send ServerOP_LSClientAuth (like you are) it still works but you are relying on world to kick people that would normally not be allowed.
|
09-21-2004, 05:56 AM
|
|
Developer
|
|
Join Date: Aug 2003
Posts: 246
|
|
Also, world does not check "locked" status of the server on LSClientAuth so users would be able to join locked servers.
I'd have to see if suspended/banned is checked on LSClientAuth or not, it might not be as world might assume it was checked on UserTotWorldRequest and would have already rejected banned/suspended accounts.
|
09-21-2004, 09:23 AM
|
Hill Giant
|
|
Join Date: Sep 2004
Posts: 184
|
|
Quote:
Originally Posted by Doodman
Also, world does not check "locked" status of the server on LSClientAuth so users would be able to join locked servers.
I'd have to see if suspended/banned is checked on LSClientAuth or not, it might not be as world might assume it was checked on UserTotWorldRequest and would have already rejected banned/suspended accounts.
|
Curious on this myself. I have a locked server that I've watched a couple people log into from the console. =P
|
09-21-2004, 09:34 AM
|
Discordant
|
|
Join Date: Jan 2004
Location: 47
Posts: 339
|
|
Prolly means their status is high enough to login through console.
LS does not interfere with console login.
|
Posting Rules
|
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
HTML code is Off
|
|
|
All times are GMT -4. The time now is 02:51 PM.
|
|
|
|
|
|
|
|
|
|
|
|
|