xboard issue

[bob]

That could be it. I had, at one point, talked to Tim about adding an occasional "ping" type operation to the remote end..

.

That is a good idea. It could perhaps send an invalid command and see if any error response comes back.

--Jon

I'll try to suggest this to HGM. It is easy to write a wrapper script to restart xboard when it exits, but it needs to exit first.

Much of the time, the connection breaks cleanly and the local TCP/IP software layer recognizes that fact and will cause reads to the socket to fail, but occasionally the thing fails without anyone knowing the connection has failed, and things hang up.

[Michel]

I'll try to suggest this to HGM. It is easy to write a wrapper script to restart xboard when it exits, but it needs to exit first.

I my own FICS client I use setjmp/longjmp to relogin when a couple of pings are missed. No need for an external script.

[hgm]

Sorry for a quick hijack here...

xBoard is at version 4.4.2? And Winboard is at 4.4.1? Correct?

I don't see a new version on the Winboard forums.

There is a WinBoard 4.4.2, but the official release took place while I was on hoiday, and I didn't get to putting it in an installer package yet. The difference between 4.4.1 and 4.4.2 was not very big (although we always have some bugfixes); the release was mainly prompted by the fact that the _source_ release of 4.4.1 had not included any WinBoard sources at all. So I did not assign it a very high priority.

But I will correct that today. and put 4.4.2 in the installer.

Perhaps I should also make an installer for 4.20100118, the developer version, which has the PV-display and variation-support features.

[hgm]

Ok, I am still investigating, but maybe it is my crappy DSL line then. The xboard debug output is not informative. I see something like the following - most of it is my own debug output, but it shows the standard commands to start a new game being received and processed. The last thing I get is "ping 9" and I send "pong 9":

Indeed, I don't see anything suspicious, or it must be that I don't see the ping 9 actually being sent. But the engine obviously received it, so it must have been sent before, and perhaps Arasan reacts to it only 0.1 sec later because it was initializing. XBoard does still seems alife after getting the acknowledgement for the seek.

5521078 <first : (debug) in save_game
5521080 <first : (debug) calling classify
5521080 <first : (debug) out of save_game
...

Btw, if you want to be fully WinBoard compliant, you should send '#' in stead of "(debug)", and add "feature debug=1" in the beginning. Then you have the guarantee that no future version of XBoard wil ever choke on some of your debug output.

5521078 <first : # in save_game
5521080 <first : # calling classify
5521080 <first : # out of save_game
...

[hgm]

That could be it. I had, at one point, talked to Tim about adding an occasional "ping" type operation to the remote end..

.

That is a good idea. It could perhaps send an invalid command and see if any error response comes back.

--Jon

I'll try to suggest this to HGM. It is easy to write a wrapper script to restart xboard when it exits, but it needs to exit first.

Much of the time, the connection breaks cleanly and the local TCP/IP software layer recognizes that fact and will cause reads to the socket to fail, but occasionally the thing fails without anyone knowing the connection has failed, and things hang up.

The current versions (4.4.2, 4.20100118) can already be set to 'ping' the ICS through a "date" command, using the -keepAlive option (which specifies the time between such pings in minutes). This was added to subvert automatic timeout by the ICS, but it could of course also serve as probe to see if the connection is healty, as "date" should produce an instantaneous reply from the ICS.

So I can add code to recognize the date string the ICS sends in reply, and use it to clear a flag that was set when sending the "date" command was sent. When the flag would still be set by the time the next "date" is up for sending, I could conclude that the connection is dead, and make a fatal error exit. (I guess I could also have any input from the ICS clear the flag.)

[Peter Skinner]

The current versions (4.4.2, 4.20100118) can already be set to 'ping' the ICS through a "date" command, using the -keepAlive option (which specifies the time between such pings in minutes). This was added to subvert automatic timeout by the ICS, but it could of course also serve as probe to see if the connection is healty, as "date" should produce an instantaneous reply from the ICS.

So I can add code to recognize the date string the ICS sends in reply, and use it to clear a flag that was set when sending the "date" command was sent. When the flag would still be set by the time the next "date" is up for sending, I could conclude that the connection is dead, and make a fatal error exit. (I guess I could also have any input from the ICS clear the flag.)

The currently implementation of -keepAlive only starts once a person plays a game. It would be nice if this feature started from first login until the client exits.

Since I am a Tournament Manager on FICS, often I am logged into the server, but I am idle doing things on my computer while waiting for someone to request a tournament. It really annoys me that often my connection times out and I lose the conversations of people, or even the last person I spoke to.

Is it possible to send the date command every 58 minutes from the start of the client?

Peter

[Richard Allbert]

!

That explains some of my logouts... I thought KeepAlive wasn't working.

Would be good if it would send date every x mins, no matter what the prgram is doing.

[hgm]

The problem was that the existing code only allowed one scheduled event, and scheduling a new one would trigger the previous one immediately. So as a quick hack I took the solution to schedule the date-ping on receiving a move (board) from the ICS. During a game, I use a scheduled event when XBoard has to play a GUI-book move on behalf of an engine that has not yet responded to ping. So a game could conceivable cause a scheduled ping to disappear, which is why I schedule at the end of the game.

But I guess there would be no harm in scheduling one immediately as well (i.e. after the first engine is loaded, as the "feature time-out" to prevent XBoard hanging when the engine does not send "feature done=1" (e.g. because it uses protocol v1), also uses a scheduled event).

An alternative would of course be to upgrade the low-level event-scheduling code to handle a list of events.

[Peter Skinner]

The problem was that the existing code only allowed one scheduled event, and scheduling a new one would trigger the previous one immediately. So as a quick hack I took the solution to schedule the date-ping on receiving a move (board) from the ICS. During a game, I use a scheduled event when XBoard has to play a GUI-book move on behalf of an engine that has not yet responded to ping. So a game could conceivable cause a scheduled ping to disappear, which is why I schedule at the end of the game.

But I guess there would be no harm in scheduling one immediately as well (i.e. after the first engine is loaded, as the "feature time-out" to prevent XBoard hanging when the engine does not send "feature done=1" (e.g. because it uses protocol v1), also uses a scheduled event).

An alternative would of course be to upgrade the low-level event-scheduling code to handle a list of events.

Not everyone uses Winboard/Xboard _just_ with engines. I use Winboard as my everyday interface to FICS/ICC.

So I would like the event to happen regardless of an engine attached or not. I think others would like this as well.

Peter

[Michel]

An alternative would of course be to upgrade the low-level event-scheduling code to handle a list of events.

I would consider this a priority. In a gui application one should be able to create timers freely.

It might also expose bugs since some code might depend on timer events occuring in a particular order.