Quote:
Originally Posted by vtecorona
New version is in the first page. Enjoy!
|
I'm afraid there's some bug in the initial ping attempts, causing a false indication of connection and thus also an unwarranted launch of ps2client, almost every time PS2ClientLoader v1.3 is started without any PS2 connected. The problem is only temporary, as the proper disconnected state is then detected and ps2client.exe terminated again, whereafter the program works properly.
To be more precise, the following is what I see with the ping delay set to 2000 ms:
Code:
Second: Behaviour:
0.0-1.9 Red Icon with no ps2client launched
2.0-7.9 Green Icon with ps2client running
8.0-etc Red Icon with ps2client terminated
Like I said above, the problem is inconsistent, and sometimes I even get several launches in a row where it doesn't happen at all, but it still happens in the majority of all my attempts.
Since it's just a temporary condition during initialization, it won't affect normal usage of the program, but it's still something you should fix.
Another thing you need to look into is how the set ping timeout affects connection state detection delays. For example, when browsing to host: in uLE there is a delay of appx 12 seconds (with same 2000ms setting) before the icon turns green. Granted that a few of those seconds are used to initialize the driver in uLE, but 12 seconds is still too long for this detection IMO. There is a similar long delay when I turn off the PS2, of appx 9-10 seconds before the icon turns red again.
I can understand a long delay in detecting a timeout, since there is no way to do that other than waiting for a reply that never comes, but I can't really understand why the resulting timeout delay is over four times larger than what the user entered (4 sequential timeouts ?).
I also can't understand why the same long delay must occur for the case where a reply is received from the other party. That makes no sense at all to me, since no timeout is occurring here. The timeout must be started, sure, but as soon as a reply is received that timeout should be terminated, and if you need another ping to confirm the connection, then this should be sent immediately after receiving the latest reply. But right now it seems to be working such that only one ping may be sent per timeout period, with the check for a received reply being made only at the end of each such period, which causes unnecessary detection delays.
Edit:
In rereading the paragraph above, I realized that you probably use the same ping method both to detect a newly established connection and to detect the failure of an existing connection (due to PS2 turn-off or ELF relaunch). That can cause delays such as discussed above, since the pings used to confirm an existing connection should only be sent once per timeout period, regardless of when the reply to each arrives.
The solution is simply to use two different methods. One for establishing connections, and another for confirming continued connections. The former should send a new ping immediately after receiving a reply, until you have the number of replies required to accept the connection as established, at which point you switch to the second method, which works approximately as your current code. The main problems are that the code for these two methods needs to be combined, and also has to handle multiple connections. Here is a brief outline of how I would do it:
You need to check for ping replies much more frequently (say each 100ms), regardless of the timeout setting, and whenever a reply is detected you need to respond differently to it depending on whether it comes from a PS2 in unconnected or already connected state. For an unconnected PS2 you increment an initial reply counter for that PS2, and if that is still less than the required amount you directly send another ping and reset the ping timer variable for that PS2, but when you have sufficient replies you just set the connection state flag for that PS2 as well as a flag to note that the last ping was replied to. And for an already connected PS2 you simply set the latter flag, to note that the latest ping was replied.
Edit2: Ooops 1! I forgot to include the 'slight detail' of launching an instance of ps2client.exe in addition to setting the connection state flag above.
Regardless of whether any reply was received in the current check period you also increment the ping timer variable of each PS2 by the check interval and see if the resulting sum exceeds the timeout value. When such a timeout occurs you always check whether the previous ping was replied to or not (copying it to another flag), after which you reset the ping reply flag of that PS2 and send it a new ping.
Now, if the previous ping had a reply, then that PS2 is already in connected state (or we wouldn't reach timeout), and the only work to do here is to clear the timeout counter of this PS2. If there was no ping reply, then you clear the initial reply counter and check if this PS2 was already connected or not. If not, then no more needs to be done here. But when you get timeout without reply for a connected PS2, you increment a timeout counter for that PS2 and check if you've reached the amount required for disconnection, in which case you reset all variables for that PS2 to initial state.
Edit2: Ooops 2! In the above I forgot to mention that 'reset all variables for that PS2' also implies terminating the ps2client.exe instance that was launched for traffic with that PS2.
Summing up variables you need:
Connection state flag for each PS2 - initialized zero == disconnected
Initial reply counter for each PS2 - initialized zero and reset at unreplied ping timeout
Last ping reply flag for each PS2 - initialized zero and reset each timeout period
Ping timer variable for each PS2 - initialized zero and reset each time a ping is sent
Ping timeout counter for each PS2 - initialized zero and reset at replied ping timeout
This method should allow the program to respond much quicker to new connections, even when using the highest timeout delay setting.
Best regards: dlanor
). It is only for the case where we receive replies from a previously unconnected PS2 that we need a quicker response, not dependent on the timeout value.
Linear Mode
