EQEmulator Forums - OpenEQ Loginserver

Page 1 of 2

Show 40 post(s) from this thread on one page

EQEmulator Forums (https://www.eqemulator.org/forums/index.php)

- Archive::Development (https://www.eqemulator.org/forums/forumdisplay.php?f=621)

- - OpenEQ Loginserver (https://www.eqemulator.org/forums/showthread.php?t=15874)

daeken_bb

09-15-2004 02:09 AM

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.

smogo

09-15-2004 04:14 AM

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

daeken_bb

09-15-2004 04:19 AM

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 :)

smogo

09-15-2004 04:40 AM

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 :(

daeken_bb

09-15-2004 04:45 AM

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 >:)

Elkay

09-20-2004 05:38 PM

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.

killspree

09-20-2004 10:08 PM

OpenEQ is a whole new client to run the game on.

Doodman

09-21-2004 02:50 AM

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.

Doodman

09-21-2004 02:55 AM

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

Doodman

09-21-2004 03:13 AM

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.

smogo

09-21-2004 03:35 AM

hmm, that's a bit too high quality as for the service i've been trying to setup. :oops: :)

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 :oops:

Doodman

09-21-2004 05:49 AM

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.

Doodman

09-21-2004 05:56 AM

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.

Elkay

09-21-2004 09:23 AM

Quote:

Originally Posted by Doodman

Curious on this myself. I have a locked server that I've watched a couple people log into from the console. =P

smogo

09-21-2004 09:34 AM

Prolly means their status is high enough to login through console.

LS does not interfere with console login.

All times are GMT -4. The time now is 12:31 AM.

Page 1 of 2

Show 40 post(s) from this thread on one page