Quote:
Originally Posted by tliu0c
Yea. That would be the bare minimum. But having something like pake would be alot better.
When the server gets a packet sent by the client, that packet is encrypted. The server needs to decrypt it. When the server sends a packet to the client, it needs to encrypt it first..Thats what I was talking about.
Yea I know that. I can imagine the ones working on the internal data processing and database stuff don't need to use pake or reverse the client. But still, I wouldn't expect such dev to come here trying to figure out how to get pake working...Don't they share knowledge in their little group?
Yeah I know and like I said before they must have had something of that sort. But I don't think they only used something so primitive tho. Why not use pake? I would imagine the ability to send packets would be really useful for debugging the server.
|
Pake is actually worse for devs. It tends to break a lot, and sucks up time that could be used for other things besides fixing it. (Not just pake, crackshield too). The custom tool does not hook the client in any way, so, barring an encryption algorithm change, never needs to be updated to work.
The server and client don't *need* packets to be encrypted. A flag in the packet indicates the presence of encryption. While it is perfectly possible for a pserver to implement encryption, most choose not to do so, because a copy-n-paste crypt algorithm invites a lot of nefarious usage. Aura, for example, sends packets unencrypted.
Actually, all three devs do things in almost every area. There are specialties, but any one of them has the tools and skills to work on any part of the core.
As stated before, pake is a hassle to get working. Instead, it is much easier to instruct the pserver to construct and send a custom packet. Plus, such a thing will always work, as long as the server and client can communicate.
Another concern with pake is that it has a tendency to leak. So releasing pake even on a dev forum or something would see it arrive in NA not too long after.