What a TLCV live broadcast looks like

[hgm]

There also exists a browser/Java-based viewer for the protocol, written by Andrew Fan (WBRGO).

The strength of TLCV is also its Achilles heel, however. To instantly update the viewers, it has to invert the server/client relationship. So that the place where the game is played can initiate transactions with the viewers. So TLCV has to configure your computer as a server, opening ports to the outside world. And of course there are all kind of security mechanisms, like firewalls, that try to prevent such a thing. So I had to do a great deal of NAPT port translation to make TLCV work, punching holes in firewalls I did not even know I had. (Not only my router, but also my modem turned out to be a gateway to another level of networks.)

If TLCV suddenly stops working, it could very well be because some link in the gateway hieararchy got assigned a new dynamic IP address, so that the NAPT setting has to be adapted.

I tried to make a viewer that would not suffer from these problem, but if the viewers cannot be reached from the outside, they should poll for changes, which leads either to excessive delays, and excessive load on the server (as there would be many needless polls before anything chanched). The nice thing with TLCV is that it gives you real-time engine output. That even beats watching comp-comp games on an ICS, where usually only the final PV is kibitzed.

My best attempt so far looked like this. (A JavaScript-driven html page.) It does show PVs, but because of the polling you will skip many, and it really only works conveniently for long TC games. And then there is the problem of server load, when you get too many viewers.

It seems that there is a technology called 'Ajax', however, which would allow a html client to keep the TLCV connection open, so that it becomes a little bit like being logged on to an ICS. The broadcast server could then simply send package along all the open connections whenever a new move or PV comes in, without the need to flood it with polls. I have never studied this, but if that works like I expect, it sounds like an ideal way to implement this.

[casaschi]

[quote="hgm"]There also exists a browser/Java-based viewer for the protocol, written by Andrew Fan ([url=http://freespace.virgin.net/andrew.fankk/]WBRGO[/url]).

The strength of TLCV is also its Achilles heel, however. To instantly update the viewers, it has to invert the server/client relationship. So that the place where the game is played can [i]initiate[/i] transactions with the viewers. So TLCV has to configure your computer as a server, opening ports to the outside world. And of course there are all kind of security mechanisms, like firewalls, that try to prevent such a thing. So I had to do a great deal of NAPT port translation to make TLCV work, punching holes in firewalls I did not even know I had. (Not only my router, but also my modem turned out to be a gateway to another level of networks.)

If TLCV suddenly stops working, it could very well be because some link in the gateway hieararchy got assigned a new dynamic IP address, so that the NAPT setting has to be adapted.

I tried to make a viewer that would not suffer from these problem, but if the viewers cannot be reached from the outside, they should poll for changes, which leads either to excessive delays, and excessive load on the server (as there would be many needless polls before anything chanched). The nice thing with TLCV is that it gives you real-time engine output. That even beats watching comp-comp games on an ICS, where usually only the final PV is kibitzed.

My best attempt so far looked [url=http://hgm.nubati.net/WCCC/game1/chess.html]like this[/url]. (A JavaScript-driven html page.) It does show PVs, but because of the polling you will skip many, and it really only works conveniently for long TC games. And then there is the problem of server load, when you get too many viewers.

It seems that there is a technology called 'Ajax', however, which would allow a html client to keep the TLCV connection open, so that it becomes a little bit like being logged on to an ICS. The broadcast server could then simply send package along all the open connections whenever a new move or PV comes in, without the need to flood it with polls. I have never studied this, but if that works like I expect, it sounds like an ideal way to implement this.[/quote]

I'd suggest you to look at the WebSocket feature often listed as part of the HTML5 family:
http://en.wikipedia.org/wiki/WebSocket

"The WebSocket protocol makes possible more interaction between a browser and a web site, facilitating live content and the creation of real-time games. This is made possible by providing a standardized way for the server to send content to the browser without being solicited by the client"

I never used it, but it would enable a javascript application from a client to setup a permanent communication channel with a server thus allowing the client to register for near real time notifications. This should give you the real time capability you are looking forward without installing a server application on the user computer (in fact, you would not install anything on the user computer, the user would use a browser and open a web page).

[hgm]

Indeed, this sounds exactly like what is needed.

The GUI could be made to upload moves and PVs real time to the server (which I imagine to be a CGI 'script'), e.g. by piggybacking them on an URL request like "?game=ID&whitePV=.............." which would receive only empty answers, and would then broadcast the info to all the logged active viewers. (Perhaps the latter should occasionally send a keep-alive request to remain logged as 'active', and be removed from the list after a time-out period.)

[casaschi]

(Perhaps the latter should occasionally send a keep-alive request to remain logged as 'active', and be removed from the list after a time-out period.)

I dont know how WebSockets work, but I'd be surprised if that functionality is not built-in in the protocol. After all, the WebSocket is fundamentally a way to establish a semi-permanent connection between a javascript borwser and a server... so managing the disconnection seems a must.

[Graham Banks]

Just as an aside, I've made contact with the TLCV programmer, Thomas McBurney, through Facebook.

I'm really hoping that he'll read this thread and perhaps sign up to Talkchess so that he can take part in discussions.

It would be great to get Tom involved in our community again, as he is obviously very talented and has a lot to offer.

TLCV is pretty good for a 10 year old piece of software!

[hgm]

One of the problems is that it is written in Power Basic, which I don't think is supported anymore. That would make it hard to make any kind of change in it. It would have to be completely rewritten.

[casaschi]

Looks like the WebSocket solution is really simple.

See the time example shown here:
https://github.com/Devristo/phpws/

Now, instead of sending to all clients time information on a regular basis, how difficult would it be for the websocket server to monitor for new chess moves and other info and send a message with that info to all connected clients?

The web application acting as client would only need to register for messages and each time a new message is received then the info is updated on the web page.

Done. And the user would not have to install any proprietary app.

[hgm]

Indeed, this sounds like the way it should be done. (I don't know PHP, however, so the given example means little to me.)

I imagine the data transferred between server and client would consist of the game moves in both formal and general coordinate notation (the former for display to the user, the latter for board update), accompanied by time remaining on the clock, as well as scores/depth and PV in formal notation. Of course there could be a chat function as well, sending text line plus author name. And I guess PGN tags should be sent as well, for player names, etc.

[Graham Banks]

Mini-boards and chat windows.