Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Better take LAN!?

Author: Peter W. Gillgasch

Date: 03:54:32 02/04/00

Go up one level in this thread


On January 28, 2000 at 18:09:09, Dann Corbit wrote:

>On January 28, 2000 at 05:17:58, Peter W. Gillgasch wrote:
>>On January 28, 2000 at 00:55:33, Harald Faber wrote:
>>>On January 27, 2000 at 15:59:57, Dann Corbit wrote:
>>>>A big problem with Auto232 players is that they are programmed wrong.
>>
>>Which Auto232 players are you talking about ?

I am still looking for an answer on this one.

>>>>I have a
>>>>solution:
>>>>Skeptical mode.
>>>>
>>>>In skeptical mode, the chess engine ignores any reset directives.  It just keeps
>>>>on pondering and changes nothing unless some actual move sequence *forces* a
>>>>change in mode.  In other words, in "skeptical" mode many of the winboard
>>>>directives are simply ignored.
>>
>>In Auto232 this is what the master should do. Either terminate the connection
>>with the slave because the damned thing doesn´t comply with the protocoll
>>or ignore. Depends.
>Serial programming is problematic on all platforms.

I don´t know. Have no problems at all under MacOS, Linux and on my
microcontrollers :)

>A lot of programs seem to have a devil of a time with it.

Well it is simple networking/communications code that is exercised
only rarely (when transmitting moves). Needs some days of testing.
Totally normal I´d say. If you do not use it often then it is likely
that you overlook something silly. The only complaints from programmers
I have seen about it came from Bob, who is a winboard/unix centric
person, so he probably did not give it as much thought/testing/experimentation
as required (no Bob bashing intended, really). I have yet to meet
a PeeCee centric programmer to complain about it.

>TCP/IP messages are a far more sensible
>approach.  Not only is is faster, but much more reliable.

Dann, excuse me. This is silly. TCP/IP is total overkill for
the task at hand, it is unportable and too complex to be implemented
in a reasonable time frame on a platform that does not support it
by default. You do not have TCP/IP on a bare DOS machine, you do
not have TCP/IP on mircrocontrollers (serial drivers are easy
to write for a small operating system kernel, how about a full
blown TCP/IP stack, puke :) on the Mac and on Windows you have
it but you really do not want to use it for any dedicated
purpose like chess specific communication.

For me the serial line makes perfect sense for that task and since
this is about cross-platform communication a unix centric solution
is not desireable at all. I can´t hook Novag machines to my stuff
if I invent my own protocoll and use TCP/IP as low level protocol.
Doesn´t buy me anything at all. Why should I care ?

I also doubt it very very much that if you can´t get simple serial
comms code working that you can get simple TCP/IP code working.

>>What has Winboard to do with it ?
>Nothing, mixing metaphors.  Some Auto232 commands resemble Winboard commands.

I see. Hm. I always wanted to ask if there is a document that describes
the Winboard interface commands (beside wading thru the source ?).

>>>>Will it help?  Actually, I think the programs that succeed _must_ already be
>>>>doing this.
>>>
>>>Wouldn't it be generally better to make it possible playing via LAN?
>>
>>A LAN per se doesn´t make things better. Why should it improve anything ?
>Faster,

Not important. You do need need more than 5 bytes per second bandwidth.

>more reliable,

I have no known problems with my serial code, so this cannot be the case.

>ready made solutions, device and operating system
>independent APIs.

Hmpff. Excuse me. This is like saying that Windows GDI calls offer
ready made solutions and device and operating system independent
APIs. Heck, as soon as you need an operating system call your
portability goes out of the window :) Even if something is POSIX.

>The list is endless.  The serial interface is an ugly
>artifact of the old CP/M and early MS-DOS days.  As a communications protocol,
>it is lame.

Well maybe. Problem is: it works __now__ for all serious programmers
and it is the industry standard (note that in contrast to my usual
pronouncation of the word standards I actually use singular :).

>>If you have the source for the affected software __fix it yourself__
>>and stop complaining ;)
>I do have it, but I'm not interested.

Then don´t complain.

> A lot of other people are though.

Then let ´em fix it :)

>If
>they are interested enough, then they will fix it.  If not, then they won't.  I
>never play Auto232 so why should it matter to me?

Then why do you post ? I am using AUTO232 and Novag UCB protocols
all day (and night :) long and it works perfectly for me.

>>Changing the transfer medium does not change the problem. If the slave
>>sends packets with master commands, the master has to cope with it. The
>>slave is broken, but the master is broken as well if he can´t handle
>>it - he communicates with his enemy so the assumption that the slave
>>is a damned uncooperative liar has to be built into your software. If
>>you don´t do this, well, you die as you do in real life :)
>
>The protocol is bad,

Well I agree a bit with that one. It could be better (but it is
not as bad as you guys always say) but as Donninger says, if you
want another protocol to fix the flaws you will probably produce
a protocol with __other__ flaws. The only serious "game playing"
flaw I can spot is the underpromotion problem in AUTO232. It is
not that important. Haven´t run into any problem related to that
issue yet :)

>the medium is bad, the whole idea is bad.  Serial
>communications is very non-standard.  It's just an entirely errant approach.

TCP/IP is very non standard. If you need more than 1 K of object code
to implement a useful subsystem, the whole concept is flawed :) How
big is the TCP/IP stack on you OS ? 64 K ? Fatware 8^)

-- Peter



This page took 0 seconds to execute

Last modified: Thu, 15 Apr 21 08:11:13 -0700

Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.