Perfect World Open Source Emulator

[tbnanubis]

You can create chars now (wohoo) but they are not saved in any way, as there is still no gamedb.

 

[Jonatas]

The database you want to create SQL directly? Unable to create any class? *-*! I am following and rooting for the fine.

 

[tbnanubis]

Characters will be stored in sql, auth will use the same sql structure we are all used to ( with readable hex passwords )

At the moment all characters you create are only produced for sending them to client, then the data is discarded by server xD

 

[Souris]

Characters will be stored in sql, auth will use the same sql structure we are all used to ( with readable hex passwords )

At the moment all characters you create are only produced for sending them to client, then the data is discarded by server xD

If by readable you mean you can get the pass from the hash, this is a huge security flaw. If not, well nevermind

Be aware that using a slow db backend like mysql will need to implement some sort of cache (like actual PW server does) where characters are saved every few minutes. Constant queries would lag the game. (I had a really good article about this but lost it now, I'll keep seeking T_T)

 

[das7002]

You can create chars now (wohoo) but they are not saved in any way, as there is still no gamedb.

Characters will be stored in sql, auth will use the same sql structure we are all used to ( with readable hex passwords )

At the moment all characters you create are only produced for sending them to client, then the data is discarded by server xD

I'm kind of interested in writing a few different interfaces for the database part (SQLite, MySQL, MSSQL, Possibly even Jet (MS Access))

Of course MySQL will be preferred but having multiple options is always nice

If I manage to get around to some basic functionality of it I'll post a 'patch' on the google code page

If by readable you mean you can get the pass from the hash, this is a huge security flaw. If not, well nevermind

Be aware that using a slow db backend like mysql will need to implement some sort of cache (like actual PW server does) where characters are saved every few minutes. Constant queries would lag the game. (I had a really good article about this but lost it now, I'll keep seeking T_T)

MySQL actually performs insanely well... Its implementations and people that don't know how to use it that make it seem slow (PHP is notorious for being slow with MySQL when doing lots of queries, in PW Chat I'm still trying to figure out better ways to insert hundreds of thousands of rows at once into MySQL (multi row inserts are slow as well from PHP))

 

[Souris]

Mysql does perform well yes, but its still not able to handle something like thousand of queries per second. Especially if you run other things on the same server. There is no need to spend double in the server when smart design from the start saves it

Some reading although not the one I was searching for:

You must be registered to see links

P.S. php insert works perfectly fine if you use php 5.3 and mysqli (

You must be registered to see links

) drivers (50k inserts in <10s)

 

[das7002]

Mysql does perform well yes, but its still not able to handle something like thousand of queries per second. Especially if you run other things on the same server. There is no need to spend double in the server when smart design from the start saves it

Some reading although not the one I was searching for:

You must be registered to see links

P.S. php insert works perfectly fine if you use php 5.3 and mysqli (

You must be registered to see links

) drivers (50k inserts in <10s)

Sure PHP can do 50k inserts in under 10s, but using something like Navicat (or mysql -u someuser -p < sqlfile.sql) on a SQL File that has 500,000 inserts can be done in less time. And yes, running ANY Database server (that is queried a lot) on the same one as a server that is running something else that is resource intensive is somewhat stupid. You could get away with it if you have a hard drive for just the database server though...

 

[MorzE]

tbnanubis, do you upload source code in AM page?

 

[tbnanubis]

the source is free available over svn.
With readable passwords, i meant you have "0xF5D4C84...." instead of weird binary stuff that is stored as varchar (i though something like "holy f**king sh*t as i saw this the first time) so this is NOT less secure, its just better for administration.
The Db structure should be like the old auth structure, but extended to hold more. The Database itself can be free of choice (using ADO.NET or ODBC)

 

[Souris]

Current password isn't binary weird stuff, its just a md5 hash base64 encoded. But yeah as long as it is properly hashed it doesn't really matter =P

 

[das7002]

Current password isn't binary weird stuff, its just a md5 hash base64 encoded. But yeah as long as it is properly hashed it doesn't really matter =P

You must be registered to see links

I wonder what base64 implementation you are using that looks like that...

Sure Aion's emu works like you stated and unless you modified the authd it just sticks the binary right into MySQL

 

[Souris]

well... base64

Edit: maybe it's because you're using the vbox version? I'm using the mysql production version modified by mono.

 

[das7002]

well... base64

Edit: maybe it's because you're using the vbox version? I'm using the mysql production version modified by mono.

I am using Vbox but not the hrace009 release... If you're saying that because of my use of Adminer instead of phpMyAdmin (which I would have used instead if it weren't for my insane tweaking of the apache mod_php php.ini to the point where phpMyAdmin refuses to run anymore(I had to use Jetty instead and Jetty (I have Tomcat and Glassfish as well for testing...) already had adminer all working nice and pretty))

And like I said, unless authd was modified to use the base64 the binary is how its stored in the db...

 

[Goodlookinguy]

And like I said, unless authd was modified to use the base64 the binary is how its stored in the db...

Actually, to correct this a bit, the base64 version is still the md5 hash in binary form. Just with base64 applied over it (Kind of pointless to be honest. It adds extra routines for no good reason.).

 

[MorzE]

$Pass = base64_encode(md5($Login.$Pass, true));

 

[das7002]

Actually, to correct this a bit, the base64 version is still the md5 hash in binary form. Just with base64 applied over it (Kind of pointless to be honest. It adds extra routines for no good reason.).

Eh... In code I use I'd probably do that as well for the simple fact that database servers can be finicky in how they handle data like that, tbh though I don't see the harm in just storing the hex string and doing a string comparison, somewhat less overhead then base64 encode/decode ontop of hashing (even as minimal as those operations are)

$Pass = base64_encode(md5($Login.$Pass, true));

Which is exactly the kind of overhead he is talking about...
md5() still has to compute the string and adding base64_encode() above that causes additional work even though modern cpus can do it in under a millisecond... (for strings as small as md5's anyway)

 

[tbnanubis]

You must be registered to see links

this is how it looked in old mssql days and how it looks in our current server. human readable but secure. the advantage over the "weird symbols" version (not base64) is that its easy to transfer data from one server to another without worrying about charset stuff which usually mess the data.

Additionally you dont run into string escaping problems.

 

[Romulan]

Noooo!!! PWI changed something to their client, we can't connect anymore to your emulator :

Screenshot:

You must be registered to see links

 

[Zorno]

Noooo!!! PWI changed something to their client, we can't connect anymore to your emulator :

Screenshot:

You must be registered to see links

Maybe they changed versionnumber ?

 

[MorzE]

Noooo!!! PWI changed something to their client, we can't connect anymore to your emulator :

Screenshot:

You must be registered to see links

Epic Fail. I can connect to the emulator from last version PWI))