Lower the time a char stays in the game after disconnect

"
The_Reporter wrote:
Only scrublets use log macros.

^^

i never used one. But i will because my inet keeps screwing me over multiple times a day.

"
if your char freezes and animations play your nw route is blocked and even the logout macro wouldn't be able to send the "logout packet" to the server.

ya, it's the freeze but animations play type.

in any case I think what ill do is I send the packet per macro and pull the cable and hope this does something.
Last edited by Toliman#6424 on Jun 14, 2017, 4:05:51 AM
"
Toliman wrote:
per macro and pull the cable and hope this does something.


won't help. the logout packet from your computer needs to get to the server.

i would really recommend doing a winmtr test while you freeze to see if there is any chance for you to fix it.

do you play on wireless? already tried to power off the router for 5 minutes so it resyncs with your provider?
age and treachery will triumph over youth and skill!
If it was a disconnect then a customizable option would help: https://www.pathofexile.com/forum/view-thread/1906926

If it is not a "full disconnect" then such an option would also make it easier for the knowledgeable user: For example manual disconnection (per macro or hardware) would then solve the problem. Right now disconnection per macro is a "hit or miss" thing which may work or leave you in game for the 6(?) secs. And disconnection by unplugging doesnt work at all now.
No wonder it's lost, it's in the middle of the jungle!
I think there are some misconceptions here.

first, 'after disconnect' concept is fairly ambiguous and honestly, flat out wrong in the context.

there is no way to precisely determine time of disconnect and that disconnect indeed happened.

you can 'decide' a disconnect has happened after not receiving a poll response back in a certain time period. and that time period should be the same for all clients and follow some conventions - if you make it too big, you will not know of a disconnect for more time, if you make it too small you'll obviously have a ton of false positives and a lot of pissed off clients who d/c for no reason.

in general, having clients determine lower-level networking timeouts on servers is an outright terrible idea. protocols exist for a reason. all clients should act the same. having server keep different timeouts for each tcp connection is a lot of overhead, especially since it has no idea what this timeout is at the time of establishing the connection. and Ill say it again, having a client determine how TCP/IP stack should be ran on the server-side goes against most concepts of client-server programming.

second, I think people still dont quite understand what logout macro does. instead of waiting for a response back, server immediately receives a proactive forged 'he's dead' message. when you pull your cable, you are disconnecting your side and server has to make that decision that someone is dead after a timeout.

so, hitting the macro and then pulling your cable right away is kinda useless. if the macro packet goes through and you got d/ced, you're good- you told them 'he's dead'. if you pull the cable while macro packet wasnt sent, you kinda just fucked yourself- you said he's dead while phone line wasnt working already. pulling the cable should only be after a certain interval and only in case where the macro clearly did not work as far as you can see on client side.
Last edited by grepman#2451 on Jun 14, 2017, 1:20:13 PM
"
grepman wrote:
Spoiler
I think there are some misconceptions here.

first, 'after disconnect' concept is fairly ambiguous and honestly, flat out wrong in the context.

there is no way to precisely determine time of disconnect and that disconnect indeed happened.

you can 'decide' a disconnect has happened after not receiving a poll response back in a certain time period. and that time period should be the same for all clients and follow some conventions - if you make it too big, you will not know of a disconnect for more time, if you make it too small you'll obviously have a ton of false positives and a lot of pissed off clients who d/c for no reason.

in general, having clients determine lower-level networking timeouts on servers is an outright terrible idea. protocols exist for a reason. all clients should act the same. having server keep different timeouts for each tcp connection is a lot of overhead, especially since it has no idea what this timeout is at the time of establishing the connection. and Ill say it again, having a client determine how TCP/IP stack should be ran on the server-side goes against most concepts of client-server programming.

second, I think people still dont quite understand what logout macro does. instead of waiting for a response back, server immediately receives a proactive forged 'he's dead' message. when you pull your cable, you are disconnecting your side and server has to make that decision that someone is dead after a timeout.

so, hitting the macro and then pulling your cable right away is kinda useless. if the macro packet goes through and you got d/ced, you're good- you told them 'he's dead'. if you pull the cable while macro packet wasnt sent, you kinda just fucked yourself- you said he's dead while phone line wasnt working already. pulling the cable should only be after a certain interval and only in case where the macro clearly did not work as far as you can see on client side.

If this is not a response to my post: Please ignore the following.
If this is a response to my post: Nothing you say here makes much sense to me. Its a lot of generic/general arguments which do not properly (if at all) apply to my suggestion.
No wonder it's lost, it's in the middle of the jungle!
"
grepman wrote:
there is no way to precisely determine time of disconnect

it's not needed. as you wrote, only the timeout on the server counts.


"
grepman wrote:
having clients determine lower-level networking timeouts on servers is an outright terrible idea.

it's no "low level" timeout, the protocol ggg uses for client server communication is built on top of tcp/ip.

the value for the timeout or the flag that enables some tech on the server to gradually lower the timeout to a certain base value if the connection is good would be transported like any other parameter that get's sent to the server (f.e. lockstep/predictive mode).

age and treachery will triumph over youth and skill!
"
vio wrote:

the value for the timeout or the flag that enables some tech on the server to gradually lower the timeout to a certain base value if the connection is good would be transported like any other parameter that get's sent to the server (f.e. lockstep/predictive mode).

lockstep/predictive is transported through application layer and it pretty much only affects the client. before it used to predict if not receiving response fast. now, it will not do anything until the response.

disconnect detection often is built right on top of tcp/ip stack and is often built in connection libraries in such a way that it can change stack settings on host level (having permissions ofc).

for example, it is that way in enterprise software I work on. there is a proprietary [and optional] protocol on top of regular connection protocol JUST for disconnect detections. in my case, client side timeout IS configurable since we have multiple servers talking to each other inside the solution, but since its used on-premise its only for 'select few' and in cloud everything is pre-set and 'locked'.

no exposed end-user clients should be able to change anytyhing disconnect detection mechanism.
Last edited by grepman#2451 on Jun 14, 2017, 5:43:54 PM
"
Zrevnur wrote:

If this is a response to my post: Nothing you say here makes much sense to me. Its a lot of generic/general arguments which do not properly (if at all) apply to my suggestion.
if I understood you correctly, you want a configurable timeout from client side (ie, in settings) in which server considers your connection as disconnected, as opposed to hardcoded one GGG has now on server side (6 seconds)

if thats indeed what you propose and I didnt misread you, my argument that is a not a good thing to have. an exposed client should in general never able to control disconnect detection on server side.
"
grepman wrote:
"
Zrevnur wrote:

If this is a response to my post: Nothing you say here makes much sense to me. Its a lot of generic/general arguments which do not properly (if at all) apply to my suggestion.
if I understood you correctly, you want a configurable timeout from client side (ie, in settings) in which server considers your connection as disconnected, as opposed to hardcoded one GGG has now on server side (6 seconds)

if thats indeed what you propose and I didnt misread you, my argument that is a not a good thing to have. an exposed client should in general never able to control disconnect detection on server side.

Instead of bringing up some general/generic opinion: Why dont you point out an actual significant disadvantage/problem of making such an option?
It should be configurable by the user. Whether its stored client or sever side doesnt matter to me.
No wonder it's lost, it's in the middle of the jungle!
"
vio wrote:

do you play on wireless? already tried to power off the router for 5 minutes so it resyncs with your provider?

dont get me started on this fucking thing
first, it goes to a local server before going to ISP, and the server ambushes me with lags 4-5 times a day
second, im on wireless and the wifi goes to a repeater before it goes to the router
third I've been resetting this router every few days for the last 8 years because it clogs up the connection without resets
and I'm not allowed to change router.

so that's how I play HC in this game

Report Forum Post

Report Account:

Report Type

Additional Info