[Question]about receiving from the Client

well am working on a (C++)Socket for the newest client and i have noticed something that i should wait like 1-2 secs after sending the SeedPacket to the Client in order to receive anydata . is that true? , or my receiving method bugged somehow!!!

bugged somehow/the way you handle the packets sending

QE.
(Stored/sent = mostly wrong depends on how its being handled)
(long (foreach's/loops/While's) before the Data.Send() cuses a huge delay sometimes)
(check any (Thread.Sleep(Milsec)) if there is any)

well idk alot about the C++ but what i mentioned was MAYBE the very first thing that well come to my/any coder mind when it comes to (1-2 sec's) delay before the AuthServer receives the packet .

hope that helps somehow .

Good Luck.

Quote:

Originally Posted by { Angelius } bugged somehow/the way you handle the packets sending

then i will try to fix it :o

Quote:

QE. (Stored/sent = mostly wrong depends on how its being handled)

the problem is the Sending/Receving methods are the same as the one i used for 4271 thats why am wondering how am facing this issue with the client patch (5395) :confused:

Quote:

(long (foreach's/loops/While's) before the Data.Send() cuses a huge delay sometimes) (check any (Thread.Sleep(Milsec)) if there is any)

nah am not using anyoff those which you have mentioned above

Quote:

well idk alot about the C++ but what i mentioned was MAYBE the very first thing that well come to my/any coder mind when it comes to (1-2 sec's) delay before the AuthServer receives the packet . hope that helps somehow . Good Luck.

thnx for your answer i appreciate it :)

I could be completely off base but if the issue takes place once you hit the game server it could be to do with the blowfish setup you are using.

The public ones released aren't that great really and can cause some issues if you're trying to process packets too fast.


I'm not thinking it's the issue in this case as you're talking about pass seed (so login phase) but I know with our new source we were using a nice threadpool to handle the async packet handling and it would actually screw up the packets because they would try to process concurrently and therefor cause blowfish to lose sync essentially.


As for the login phase on current patch... you don't really need to do any delay.


Client connects to auth server
Auth server sends password seed
Client sends auth request (with encrypted password using pass seed)
server sends auth response packet

Boom, done with login server. There's simply nothing more to it.

Personally I always send the password seed right as I create the instance of my login client object... there's no delays in use and I've never had a single issue.

Quote:

Originally Posted by pro4never I could be completely off base but if the issue takes place once you hit the game server it could be to do with the blowfish setup you are using. The public ones released aren't that great really and can cause some issues if you're trying to process packets too fast. I'm not thinking it's the issue in this case as you're talking about pass seed (so login phase) but I know with our new source we were using a nice threadpool to handle the async packet handling and it would actually screw up the packets because they would try to process concurrently and therefor cause blowfish to lose sync essentially. As for the login phase on current patch... you don't really need to do any delay. Client connects to auth server Auth server sends password seed Client sends auth request (with encrypted password using pass seed) server sends auth response packet Boom, done with login server. There's simply nothing more to it. Personally I always send the password seed right as I create the instance of my login client object... there's no delays in use and I've never had a single issue.

i see ,then i guess there is something wrong with my receving method since am using boost::asio::async_read to async the recevining data and also it should be automatically handel the timer(if it should to wait inorder to receive or not) , i will work on the receving method again hopefully i can findout what's wrong there!, and thanks for your answer i appreciate it

I have had this problem before on a source I started around Jan, I sent the authseed but never received any Data back. Therefor I ditched the source because something was seriously fucked up(other big problems has become noticable) and seemed to only login to 5165 and below. Check through everything, What I did when that problem came was I started checking times on how long it took to do certian things(blowfish, send that packet) and then breakpoint to check for any funny values in the packet and various otherstuff.

Quote:

Originally Posted by _DreadNought_ I have had this problem before on a source I started around Jan, I sent the authseed but never received any Data back. Therefor I ditched the source because something was seriously fucked up(other big problems has become noticable) and seemed to only login to 5165 and below. Check through everything, What I did when that problem came was I started checking times on how long it took to do certian things(blowfish, send that packet) and then breakpoint to check for any funny values in the packet and various otherstuff.

yeah thats what am trying to do , BUT I CAN'T FINDOUT WHAT'S WRONG :mad:

Is it a custom socket system that you coded?

#edit
800th post =))

Quote:

Originally Posted by _DreadNought_ Is it a custom socket system that you coded? #edit 800th post =))

yeah i'm,and the socket is using boost::asio from boost library lol

Breakpoint the receive method to see if its just bottle necked somewhere later down the line or if there really is a 2 second delay in receiving the data, also ensure that the send method is actually sending when you call it or if thats also being bottle necked somewhere else.

A 2 second delay is really unusual though, even if something was waiting for a lock to be released it shouldnt take 2 seconds. I find the whole thing really strange =/

Possibly recheck your socket system? or maybe reinstall the client a couple patches up? :P

Quote:

Originally Posted by Korvacs Breakpoint the receive method to see if its just bottle necked somewhere later down the line or if there really is a 2 second delay in receiving the data, also ensure that the send method is actually sending when you call it or if thats also being bottle necked somewhere else. A 2 second delay is really unusual though, even if something was waiting for a lock to be released it shouldnt take 2 seconds. I find the whole thing really strange =/

Indeed it is strange, i fixed it though the receive method was bugged somehow am made it all over again :), thnx for your answer :)

Quote:

Originally Posted by _DreadNought_ Possibly recheck your socket system? or maybe reinstall the client a couple patches up? :P

nah it's the receive method and i fixed it :) thnx

Glad so, I've requested it be closed for you.