Rob Ryan Feb 6 1994, 4:29 am show options Newsgroups: rec.games.chess From: r...@panix.com (Rob Ryan) - Find messages by this author Date: 6 Feb 1994 07:29:20 -0500 Local: Sun, Feb 6 1994 4:29 am Subject: Re: "free" ICS vs. "Controled" ICS solution Reply to Author | Forward | Print | Individual Message | Show original | Report Abuse In <9402060444.AA07...@moose.usmcs.maine.edu> mail...@moose.usmcs.maine.edu (Edward Maillet) writes: > ... The problem with decentralized >ICS control is that each server probably ends up with its own ratings setup >(leading to a total inconsistent Internet ratings system) and other >inconsistent things typical of decentralized control. ... What exactly is the problem? How inconsistent are the ratings? -- Rob Edward Maillet Feb 6 1994, 3:31 pm show options Newsgroups: rec.games.chess From: mail...@moose.usmcs.maine.edu (Edward Maillet) - Find messages by this author Date: 5 Feb 1994 22:44:25 -0600 Local: Sat, Feb 5 1994 8:44 pm Subject: "free" ICS vs. "Controled" ICS solution Reply to Author | Forward | Print | Individual Message | Show original | Report Abuse The big complaint over ICS seems to be that of control. Some think a "free" (note the quotes!) ICS is THE solution. The problem with decentralized ICS control is that each server probably ends up with its own ratings setup (leading to a total inconsistent Internet ratings system) and other inconsistent things typical of decentralized control . If we had a centralized ratings server (like the old days) that handled ratings for ALL ICS servers that come along we can cut down on inconsistenties. All that needs to be done is define a method of ICS site informing the ratings server of results. A simple task. I know there are those that HATE the idea of a central ratings server because of link problems, etc. Fortunately, most of the problems surrounding a separate ratings server can be solved with a simple change of how ICS handles ratings. The probelm that most had with a separate ratings server was trying to update it from multiple ICS sites and losing connections to the server. If ICS didn't update ratings instantly, but updated on a less frequent basis (monthly, weekly, or daily?) maintaining a separate ratings server becomes possible (simple even!) All ICS sites would have to do is mail game results to the ratings server every 24-hours or something. ICS sites would only have to register their existance with the ratings server and send game results in the mail! NO central control over ICS sites! ----- Ed Maillet (White) ip05...@portland.maine.edu mail...@moose.usmcs.maine.edu Ghica Feb 9 1994, 8:17 am show options Newsgroups: rec.games.chess From: g...@fig.citib.com (Ghica) - Find messages by this author Date: 9 Feb 1994 11:17:26 -0500 Local: Wed, Feb 9 1994 8:17 am Subject: Re: "free" ICS vs. "Controled" ICS solution Reply to Author | Forward | Print | Individual Message | Show original | Report Abuse In article <2j2nr0$...@panix2.panix.com>, r...@panix.com (Rob Ryan) writes: |> In <9402060444.AA07...@moose.usmcs.maine.edu> mail...@moose.usmcs.maine.edu (Edward Maillet) writes: |> |> > ... The problem with decentralized |> >ICS control is that each server probably ends up with its own ratings setup |> >(leading to a total inconsistent Internet ratings system) and other |> >inconsistent things typical of decentralized control. ... |> |> What exactly is the problem? How inconsistent are the ratings? |> |> -- Rob pick up any copy of a book that deals with distributed databases, client-server concepts, one and two phase commits etc etc, and then you'll have a clearer picture of the issues involved. Any DCE book or a book by C.J. Date should have a chapter or two on synchronization issues. Otherwise the question is as vague as "what exactly is the problem with building a 100 stories building? I can build a barn just fine!" ;-) -rg -rg Ole Tange Feb 9 1994, 10:39 am show options Newsgroups: rec.games.chess From: t...@daimi.aau.dk (Ole Tange) - Find messages by this author Date: 9 Feb 1994 18:39:38 GMT Local: Wed, Feb 9 1994 10:39 am Subject: Re: "free" ICS vs. "Controled" ICS solution Reply to Author | Forward | Print | Individual Message | Show original | Report Abuse Thus spake arsen...@newton.ccs.tuns.ca (Peter Arsenault): >> (Lots of info) >I agree TOTALLY! Have lots of ICS servers, which keeps lag to a minimum, >and a central machine to do ratings on a weekly basis! And have app. 3 players on each server, what a brilliant idea!!! >-- Peter Arseneau AnteTempore -- - Du spilder ikke tider, hva'? - Det skal man heller ikke. Russian Pizza Blues James Aspnes Feb 9 1994, 10:50 am show options Newsgroups: rec.games.chess From: aspnes-ja...@cs.yale.edu (James Aspnes) - Find messages by this author Date: 9 Feb 1994 13:50:01 -0500 Local: Wed, Feb 9 1994 10:50 am Subject: Re: "free" ICS vs. "Controled" ICS solution Reply to Author | Forward | Print | Individual Message | Show original | Report Abuse In article <2jb2an$...@duck.ftn.us-ny.citicorp.com> g...@fig.citib.com (Ghica) writes: In article <2j2nr0$...@panix2.panix.com>, r...@panix.com (Rob Ryan) writes: |> In <9402060444.AA07...@moose.usmcs.maine.edu> mail...@moose.usmcs.maine.edu (Edward Maillet) writes: |> |> > ... The problem with decentralized |> >ICS control is that each server probably ends up with its own ratings setup |> >(leading to a total inconsistent Internet ratings system) and other |> >inconsistent things typical of decentralized control. ... |> |> What exactly is the problem? How inconsistent are the ratings ? pick up any copy of a book that deals with distributed databases, client-server concepts, one and two phase commits etc etc, and then you'll have a clearer picture of the issues involved. Any DCE book or a book by C.J. Date should have a chapter or two on synchronization issues . Bullshit. Synchronization is only necessary if you want to guarantee synchronous behavior. This is a good example of the danger of learning so much about a set of techniques that you forget when not to use them. Unless you have a lot of users each playing games on multiple servers simultaneously, it should be perfectly acceptable to use an asynchronous central rating database with local rating information only updated every now and then (say the central database sends out updates every six hours). Local servers can maintain "performance ratings" based on locally-available information that are superseded by the central server's updates. All of this can be done with no more infrastructure than what is already provided by the mail system. Otherwise the question is as vague as "what exactly is the problem with building a 100 stories building? I can build a barn just fine !" ;-) Perhaps the question to you should be "How do you think the USCF manages?" After all, they have tournaments going on all the time, and I'd bet most of the USCF brass have never heard of C.J. Date. --Jim Aspnes Robert Hyatt Feb 9 1994, 11:40 am show options Newsgroups: rec.games.chess From: h...@cis.uab.edu (Robert Hyatt) - Find messages by this author Date: Wed, 9 Feb 1994 19:40:11 GMT Local: Wed, Feb 9 1994 11:40 am Subject: Re: "free" ICS vs. "Controled" ICS solution Reply to Author | Forward | Print | Individual Message | Show original | Report Abuse - Hide quoted text - - Show quoted text - In article <2jbb8pINN...@PINE.THEORY.CS.YALE.EDU> aspnes-ja...@cs.yale.edu (James Aspnes) writes: >In article <2jb2an$...@duck.ftn.us-ny.citicorp.com> g...@fig.citib.com (Ghica) writes: > In article <2j2nr0$...@panix2.panix.com>, r...@panix.com (Rob Ryan) writes: > |> In <9402060444.AA07...@moose.usmcs.maine.edu> mail...@moose.usmcs.maine.edu (Edward Maillet) writes: > |> > |> > ... The problem with decentralized > |> >ICS control is that each server probably ends up with its own ratings setup > |> >(leading to a total inconsistent Internet ratings system) and other > |> >inconsistent things typical of decentralized control. ... > |> > |> What exactly is the problem? How inconsistent are the ratings? > pick up any copy of a book that deals with distributed databases, > client-server concepts, one and two phase commits etc etc, and then > you'll have a clearer picture of the issues involved. > Any DCE book or a book by C.J. Date should have a chapter or two on > synchronization issues. >Bullshit. Synchronization is only necessary if you want to guarantee >synchronous behavior. >This is a good example of the danger of learning so much about a set >of techniques that you forget when not to use them. Unless you have a >lot of users each playing games on multiple servers simultaneously, it >should be perfectly acceptable to use an asynchronous central rating >database with local rating information only updated every now and then >(say the central database sends out updates every six hours). Local >servers can maintain "performance ratings" based on locally-available >information that are superseded by the central server's updates. >All of this can be done with no more infrastructure than what is >already provided by the mail system. > Otherwise the question is as vague as "what exactly is the problem with > building a 100 stories building? I can build a barn just fine!" ;-) >Perhaps the question to you should be "How do you think the USCF >manages?" After all, they have tournaments going on all the time, and >I'd bet most of the USCF brass have never heard of C.J. Date. I hate to jump in, but this is definitely not "bullshit." If you don't synchronize these "parallel databases" then you will have what might be called "non-deterministic bullshit." It only takes a few "hits" in such a distributed application to completely corrupt the data that is shared... As far as your reference to USCF, it doesn't make any sense... USCF computes ratings SEQUENTIALLY as tournament results come in... you don't have two different branches computing ratings at the same time and then try to "combine" them which is nearly impossible to do... when you rate two tournaments in parallel rather than sequentially, I would have 3 ratings: (1) pre-tournament rating (2) post-tournament 1 rating and (2) post-tournament 2 rating. In rating my opponents (and me) in tournament 2 what would happen if you use my pre-tournament rating? my post tournament 1 rating? Two completely different ratings for me (and for my opponents). Doing things sequentially is easy... doing them in parallel is messy... -- !Robert Hyatt Computer and Information Sciences ! !hy...@cis.uab.edu University of Alabama at Birmingham ! James Aspnes Feb 9 1994, 1:17 pm show options Newsgroups: rec.games.chess From: aspnes-ja...@cs.yale.edu (James Aspnes) - Find messages by this author Date: 9 Feb 1994 16:17:54 -0500 Local: Wed, Feb 9 1994 1:17 pm Subject: Re: "free" ICS vs. "Controled" ICS solution Reply to Author | Forward | Print | Individual Message | Show original | Report Abuse In article <1994Feb9.194011.8...@cis.uab.edu> h...@cis.uab.edu (Robert Hyatt) writes: I hate to jump in, but this is definitely not "bullshit." If you don't synchronize these "parallel databases" then you will have what might be called "non-deterministic bullshit." It only takes a few "hits" in such a distributed application to completely corrupt the data that is shared ... There are no "parallel databases". There is an authoritative database, and there are non-authoritative copies that may contain inconsistent, out-of-date views. Updates to the authoritative database are completely sequential. We can even do ratings updates in timestamp order if we are willing to store a week or two of game results so that delayed game results can be inserted in the proper order. "Bullshit" is a strong term, and I shouldn't have used it. The previous poster correctly pointed out that maintaining a consistent distributed database is difficult. Not realizing that maintaining a consistent distributed database in this case is unnecessary (or, equivalently, almost impossible, meaning that even users that want it won't get it) is not so much an act of spreading bullshit as an example of not seeing the non-technical solution because one is too well-versed in the technical solutions. A trap I fear you may also be falling into. As far as your reference to USCF, it doesn't make any sense... USCF computes ratings SEQUENTIALLY as tournament results come in... you don't have two different branches computing ratings at the same time and then try to "combine" them which is nearly impossible to do ... Precisely. USCF serializes tournaments at a central location based on mailed-in reports, and then mails out periodic snapshots of its ratings database. My proposal would serialize games at a central location based on mailed-in reports, and then mail out periodic snapshots of the ICS ratings database. If you see a problem with this, you're going to have to point it out more specifically than just reaching for the first example in any distributed database book. --Jim Aspnes Robert Hyatt Feb 10 1994, 9:47 am show options Newsgroups: rec.games.chess From: h...@cis.uab.edu (Robert Hyatt) - Find messages by this author Date: Thu, 10 Feb 1994 17:47:27 GMT Local: Thurs, Feb 10 1994 9:47 am Subject: Re: "free" ICS vs. "Controled" ICS solution Reply to Author | Forward | Print | Individual Message | Show original | Report Abuse - Hide quoted text - - Show quoted text - In article <2jbju2INN...@PINE.THEORY.CS.YALE.EDU> aspnes-ja...@cs.yale.edu (James Aspnes) writes: >In article <1994Feb9.194011.8...@cis.uab.edu> h...@cis.uab.edu (Robert Hyatt) writes: > I hate to jump in, but this is definitely not "bullshit." If you don't > synchronize these "parallel databases" then you will have what might > be called "non-deterministic bullshit." It only takes a few "hits" > in such a distributed application to completely corrupt the data that > is shared... >There are no "parallel databases". There is an authoritative >database, and there are non-authoritative copies that may contain >inconsistent, out-of-date views. Updates to the authoritative >database are completely sequential. We can even do ratings updates in >timestamp order if we are willing to store a week or two of game >results so that delayed game results can be inserted in the proper >order. >"Bullshit" is a strong term, and I shouldn't have used it. The >previous poster correctly pointed out that maintaining a consistent >distributed database is difficult. Not realizing that maintaining a >consistent distributed database in this case is unnecessary (or, >equivalently, almost impossible, meaning that even users that want it >won't get it) is not so much an act of spreading bullshit as an >example of not seeing the non-technical solution because one is too >well-versed in the technical solutions. A trap I fear you may also be >falling into. > As far as your reference to USCF, it doesn't make any sense... USCF > computes ratings SEQUENTIALLY as tournament results come in... you > don't have two different branches computing ratings at the same time > and then try to "combine" them which is nearly impossible to do... >Precisely. USCF serializes tournaments at a central location based on >mailed-in reports, and then mails out periodic snapshots of its >ratings database. My proposal would serialize games at a central >location based on mailed-in reports, and then mail out periodic >snapshots of the ICS ratings database. If you see a problem with >this, you're going to have to point it out more specifically than just >reaching for the first example in any distributed database book. >--Jim Aspnes The only problem is "currentness" related to ratings. Doing it right isn't hard, so why do it wrong? ie, I play a few games on ICS1 and get one rating, a few games on ICS2 and get a second rating, and so forth. Why let ratings drift toward wrong values when a centralized client-server database solves the problem.... results are reported and correct ratings are always available.... Again, I simply don't like the idea of maintaining something that is inherently wrong, just because calculating it is more simple than developing a system that works correctly. -- ! Robert Hyatt Computer and Information Sciences ! !hy...@cis.uab.edu University of Alabama at Birmingham ! James Aspnes Feb 10 1994, 2:43 pm show options Newsgroups: rec.games.chess From: aspnes-ja...@cs.yale.edu (James Aspnes) - Find messages by this author Date: 10 Feb 1994 17:43:01 -0500 Local: Thurs, Feb 10 1994 2:43 pm Subject: Re: "free" ICS vs. "Controled" ICS solution Reply to Author | Forward | Print | Individual Message | Show original | Report Abuse In article <1994Feb10.174727.10...@cis.uab.edu> h...@cis.uab.edu (Robert Hyatt) writes: In article <2jbju2INN...@PINE.THEORY.CS.YALE.EDU> aspnes-ja...@cs.yale.edu (James Aspnes ) writes: > Precisely. USCF serializes tournaments at a central location based on >mailed-in reports, and then mails out periodic snapshots of its >ratings database. My proposal would serialize games at a central >location based on mailed-in reports, and then mail out periodic >snapshots of the ICS ratings database. If you see a problem with >this, you're going to have to point it out more specifically than just >reaching for the first example in any distributed database book. >--Jim Aspnes Pizza Feb 12 1994, 2:08 pm show options Newsgroups: rec.games.chess From: z...@comp.tamu.edu (Pizza) - Find messages by this author Date: 12 Feb 1994 16:08 CST Subject: Re: "free" ICS vs. "Controled" ICS solution Reply to Author | Forward | Print | Individual Message | Show original | Report Abuse >And have app. 3 players on each server, what a brilliant idea!!! >>-- Peter Arseneau >AnteTempore >-- >- Du spilder ikke tider, hva'? >- Det skal man heller ikke. Russian Pizza Blues ^^^^^ What does this mean?? um?? um?? UMMMMM????????????????????????? !! .. Urban Koistinen Feb 12 1994, 2:18 pm show options Newsgroups: rec.games.chess From: md85-...@hemul.nada.kth.se (Urban Koistinen) - Find messages by this author Date: 12 Feb 1994 22:18:01 GMT Local: Sat, Feb 12 1994 2:18 pm Subject: Re: "free" ICS vs. "Controled" ICS solution Reply to Author | Forward | Print | Individual Message | Show original | Report Abuse In <2jed9lIN...@ PINE.THEORY.CS.YALE.EDU> aspnes-ja...@cs.yale.edu (James Aspnes) writes : >Doing it right is _impossible_. The proof is almost trivial: suppose >that the network fails so that I can talk to both ICS1 and ICS2 but >neither can talk to the other or to the centralized ratings server you >suggested later in your message (this sort of failure is actually >quite common on the Internet). I play a few games on ICS1 and get one >rating, and I play a few games on ICS2 and get another rating. So who >is going to tell me what my current rating is? (I can't even keep >track of it myself, since I don't know what the current ratings of my >opponents are.) If everyone keep track of their own rating, then it could be current all the time. You would have to transmit it when you log on to a server or when asked and when you begin/end a game. Maybe someone would write a program to do this automatically. Anyone would be able to lie about their rating, but as it is all for fun it should not matter. The servers could post results so that abusers can be found out. -- Urban Koistinen - md85-...@nada.kth.se Stop software patents, interface copyrights: contact l...@uunet.uu.net Peter Arsenault Feb 14 1994, 1:24 pm show options Newsgroups: rec.games.chess From: arsen...@newton.ccs.tuns.ca (Peter Arsenault) - Find messages by this author Date: Mon, 14 Feb 1994 21:24:46 GMT Local: Mon, Feb 14 1994 1:24 pm Subject: Re: "free" ICS vs. "Controled" ICS solution Reply to Author | Forward | Print | Individual Message | Show original | Report Abuse t...@daimi.aau.dk (Ole Tange) writes: >>I agree TOTALLY! Have lots of ICS servers, which keeps lag to a minimum, >>and a central machine to do ratings on a weekly basis! >And have app. 3 players on each server, what a brilliant idea!!! Thanks for the sarcasm. It made my day. >AnteTempore Sorry, but I can't agree with your assessment of the situation. There wouldn't be just 3 players on average per server at one time. I just logged in to UOKNOR and counted 25 games and 15 players, making 65 total. What's the count when the server is busy?? And how many others are hidden, heaven forbid. What good is it having 65 different people on at once? How many of them would you play? 5? How many of them would you have enlightening conversations with? How many people listen to shouting? Say there are just 10 people shouting. Every shout means 10 messages are sent over the net. If all 10 of them shout once, that makes 100. Say there were 10 servers. OK, that makes 6 people on average. Anything wrong with 6? Is that too few?? Doesn't sound too bad to me. Also consider this. One server could be for WILD games, another for TEAM games, another STANDARD, another for BLITZERs < 1200; another, B < 1500; B < 1800, B < 2100, etc. I wouldn't make them exclusive mind you, but at least you'd know the type of player you'd be meeting. (We could also have a server for SHOUTERS and former ADMINS if you like). What's the good of having 65 people when those rated above 2000 wouldn't play someone under 1500 under any circumstances? And that's what's happening too. It's a WASTE!! Splitting these people up won't make one bit of difference, except for a more efficient ICSN. (Internet Chess Server Net) ======================================================== + Peter Arseneau + PeterPuck _ * + 2515 Brunswick Street + // * + Halifax, Nova Scotia + (ICS) // * + + _____// * + (902) 429-3794 + |_____/ * ======================================================== Peter Arsenault Feb 14 1994, 1:29 pm show options Newsgroups: rec.games.chess From: arsen...@newton.ccs.tuns.ca (Peter Arsenault) - Find messages by this author Date: Mon, 14 Feb 1994 21:29:40 GMT Local: Mon, Feb 14 1994 1:29 pm Subject: Re: "free" ICS vs. "Controled" ICS solution Reply to Author | Forward | Print | Individual Message | Show original | Report Abuse >In <2jed9lIN...@PINE.THEORY.CS.YALE.EDU> aspnes-ja...@cs.yale.edu (James Aspnes) writes: >>Doing it right is _impossible_. The proof is almost trivial: suppose >>that the network fails so that I can talk to both ICS1 and ICS2 but >>neither can talk to the other or to the centralized ratings server you >>suggested later in your message (this sort of failure is actually >>quite common on the Internet). I play a few games on ICS1 and get one >>rating, and I play a few games on ICS2 and get another rating. So who >>is going to tell me what my current rating is? (I can't even keep >>track of it myself, since I don't know what the current ratings of my >>opponents are.) Just put a time stamp on every game. Ratings would be updated weekly. The central machine would proceed with the rating calculations starting with the first game played. It's EASY!! ======================================================== + Peter Arseneau + PeterPuck _ * + 2515 Brunswick Street + // * + Halifax, Nova Scotia + (ICS) // * + + _____// * + (902) 429-3794 + |_____/ * ======================================================== David B Pecora Feb 15 1994, 4:25 pm show options Newsgroups: rec.games.chess From: b...@athena.mit.edu (David B Pecora) - Find messages by this author Date: 16 Feb 1994 00:25:14 GMT Local: Tues, Feb 15 1994 4:25 pm Subject: Re: "free" ICS vs. "Controled" ICS solution Reply to Author | Forward | Print | Individual Message | Show original | Report Abuse It has been suggested by a couple of people that a bunch of splinter ICS's be created to fix the lag problem. As I understand it, lag is a problem with the networks and not a function of the number of players on the server at the time. I have experienced major lag at the euro-ics too. Aside from this point, it's unclear what purpose segregating the ICS's would serve. Just think of all the annoyances you would have: if you were playing standard and you wanted to play blitz, you would have to disconnect and reconnect to a different server. If you were looking for somebody, you would have to search through maybe 10 servers before finding him or concluding that he was not on any (and what if he connected to one after you searched it?) This situation would be analogous to a city having several libraries, one for nonfiction books, another for fiction, another for reference, etc., but where books were permitted to circulate thorugh at random, and where there is no inter-library computer link. > Say there were 10 servers. OK, that makes 6 people on average. > Anything wrong with 6? Is that too few?? Doesn't sound too bad to me. This sentiment, which was echoed amidst complaints about shouting, admins, and snobbish higher-rated players, seems rather hostile to me. A possible solution, if you're fed up with the american ics, is to simply move to the euro-ics, which has a lot less people, games, admins, and shouting. But I think the fact that there are NOT an equal number of people at the two main ics sites currently in use should indicate that most are not in favor of splintering. David James Aspnes Feb 15 1994, 7:53 pm show options Newsgroups: rec.games.chess From: aspnes-ja...@cs.yale.edu (James Aspnes) - Find messages by this author Date: 15 Feb 1994 22:53:53 -0500 Local: Tues, Feb 15 1994 7:53 pm Subject: Re: "free" ICS vs. "Controled" ICS solution Reply to Author | Forward | Print | Individual Message | Show original | Report Abuse In article <2jrp5a$...@senator-bedfellow.MIT.EDU> b...@athena.mit.edu (David B Pecora) writes: But I think the fact that there are NOT an equal number of people at the two main ics sites currently in use should indicate that most are not in favor of splintering . One of the nicest things about freedom is you don't have to take advantage of it. If indeed everybody will want to be on the most popular ICS (which is what I expect will happen in any case), then having three dozen other ones won't stop them. But it would let the users decide which ICS would be the most popular... Richard "red" Nash Feb 16 1994, 5:08 am show options Newsgroups: rec.games.chess From: n...@visus.com (Richard "red" Nash) - Find messages by this author Date: Wed, 16 Feb 1994 13:08:25 GMT Local: Wed, Feb 16 1994 5:08 am Subject: Re: "free" ICS vs. "Controled" ICS solution Reply to Author | Forward | Print | Individual Message | Show original | Report Abuse In article < - Hide quoted text - - Show quoted text - 2jed9lIN...@PINE.THEORY.CS.YALE.EDU> aspnes-ja...@cs.yale.edu (James Aspnes) writes: > In article <1994Feb10.174727.10...@cis.uab.edu> h...@cis.uab.edu (Robert Hyatt) writes: > In article <2jbju2INN...@PINE.THEORY.CS.YALE.EDU> aspnes-ja...@cs.yale.edu (James Aspnes) writes: > >Precisely. USCF serializes tournaments at a central location based on > >mailed-in reports, and then mails out periodic snapshots of its > >ratings database. My proposal would serialize games at a central > >location based on mailed-in reports, and then mail out periodic > >snapshots of the ICS ratings database. If you see a problem with > >this, you're going to have to point it out more specifically than just > >reaching for the first example in any distributed database book. > >--Jim Aspnes > The only problem is "currentness" related to ratings. Doing it right > isn't hard, so why do it wrong? > Doing it right is _impossible_. The proof is almost trivial: suppose Another point is that daily (or even weekly) fluctuations in your rating are meaningless anyway. "Doing it right" isn't necessarily right. A less frequent update of rating is probably more accurate. It wouldn't be as sensitive to having a bad day. BTW: I will be writing the code for a update-by-mail central ratings database in the next few weeks. -- +---------------------------------------------------------------+ | Richard V. Nash | Visual Understanding Systems, Inc. | | n...@visus.com | Tel. (412)-488-3600 Fax. (412)-488-3611 | +---------------------------------------------------------------+ Karl Schwamb Feb 16 1994, 9:46 am show options Newsgroups: rec.games.chess From: schw...@isi.edu (Karl Schwamb) - Find messages by this author Date: 16 Feb 1994 17:46:18 GMT Local: Wed, Feb 16 1994 9:46 am Subject: Re: "free" ICS vs. "Controled" ICS solution Reply to Author | Forward | Print | Individual Message | Show original | Report Abuse > But I think the fact that there are NOT an equal number of people > at the two main ics sites currently in use should indicate that most > are not in favor of splintering. There's no reason a client program like XICS couldn't be changed to allow connections to multiple servers. This would allow greater diversity without forcing you to choose one server at a time. The display could show all users present (irrespective of site). If you want to play a game with someone, the client program could easily figure out a server to use (one in common with both players and running with the least lag). Commands at the servers could be changed to apply to either the chess "community" as a whole or the local server. This would allow an atmosphere much like the Internet Town Hall run over the MBONE although the multicasting would be emulated over the network since MBONE is not widespread (yet). The idea is that we put chess playing and users first -- avoiding the restrictions provided by a single server. I've got the server code created and newly distributed by Michael Moore (Thank You, Michael!). I encourage all interested parties to get it and start thinking about the positive steps we can take to create a better, more democratic chess community on the Internet. -Karl Joseph Albert Feb 16 1994, 2:34 pm show options Newsgroups: rec.games.chess From: alb...@trigger.cs.wisc.edu (Joseph Albert) - Find messages by this author Date: 16 Feb 1994 22:34:07 GMT Local: Wed, Feb 16 1994 2:34 pm Subject: Re: "free" ICS vs. "Controled" ICS solution Reply to Author | Forward | Print | Individual Message | Show original | Report Abuse In article <2jrp5a$...@senator-bedfellow.MIT.EDU> b...@athena.mit.edu (David B Pecora) writes : >It has been suggested by a couple of people that a bunch of splinter ICS's >be created to fix the lag problem. As I understand it, lag is a problem with >the networks and not a function of the number of players on the server at >the time. I have experienced major lag at the euro-ics too. There are at least 4 possible sources of lag: 1) lag from the internet-- ie networks across which a chess move must be moved to get to the LAN on which the ICS host lives from your system. 2) lag because of network traffic on the LAN where ICS lives-- your packet may have arrived at the local ICS site, but has not yet been delivered to the ICS host. 3) lag from resource bottlenecks on the machine where ICS running. 4) lag from ICS having too many moves to process ahead of yours. one might consider (4) as a special case of (3). in any case, having multiple servers will significantly help with 2, 3, and 4. having multiple servers will also help with (1), since it may be that the internet is having trouble getting packets to one particular site, but not another, or different people can use different servers, choosing the one where they get a good connection. Joseph Albert alb...@cs.wisc.edu Jeffrey Schoenborn Feb 18 1994, 9:00 am show options Newsgroups: rec.games.chess From: jscho...@csugrad.cs.vt.edu (Jeffrey Schoenborn) - Find messages by this author Date: 18 Feb 1994 12:00:28 -0500 Local: Fri, Feb 18 1994 9:00 am Subject: Re: "free" ICS vs. "Controled" ICS solution Reply to Author | Forward | Print | Individual Message | Show original | Report Abuse > Say there were 10 servers. OK, that makes 6 people on average. >Anything wrong with 6? Is that too few?? Doesn't sound too bad to me. Yes, 6 is too few. It is not always easy to find an opponent when there are very few people on. the Euro server usually (when I check) has about 10-15 players on at any given time. Usually there is at most one player idle. If that player is rated much higher than me, it usually means that I will get destroyed; if he is rated much lower, the game is usually less interesting. Also, I like to play the same player a couple of times then play someone else. If there is nobody else to play, it is less enjoyable. > Also consider this. One server could be for WILD games, another for >TEAM games, another STANDARD, another for BLITZERs < 1200; another, B < 1500; >B < 1800, B < 2100, etc. I wouldn't make them exclusive mind you, but >at least you'd know the type of player you'd be meeting. >(We could also have a server for SHOUTERS and former ADMINS if you like). This is the only reasonable way of breaking up the servers. Of course, requiring that people play on certain servers would be bad, suggesting it would be ok. The only problem with the breaking them up according to the type of games that people want to play is that often people want to play different games. I like to play wild and standard occasionally, but I would never log onto that server, rather I would play such a game if I was challenged. > What's the good of having 65 people when those rated above 2000 wouldn't >play someone under 1500 under any circumstances? And that's what's >happening too. It's a WASTE!! Splitting these people up won't make one bit >of difference, except for a more efficient ICSN. (Internet Chess Server Net) -- Jeff Jeffrey Schoenborn Feb 18 1994, 9:04 am show options Newsgroups: rec.games.chess From: jscho...@csugrad.cs.vt.edu (Jeffrey Schoenborn) - Find messages by this author Date: 18 Feb 1994 12:04:56 -0500 Local: Fri, Feb 18 1994 9:04 am Subject: Re: "free" ICS vs. "Controled" ICS solution Reply to Author | Forward | Print | Individual Message | Show original | Report Abuse schw...@isi.edu (Karl Schwamb) writes: >> But I think the fact that there are NOT an equal number of people >> at the two main ics sites currently in use should indicate that most >> are not in favor of splintering. Agreed. >There's no reason a client program like XICS couldn't be changed >to allow connections to multiple servers. This would allow greater But that defeats the whole purpose of having the multiple servers; you would have to be connected to each at the same time. If it was setup like a finger, then there would be dozens of fingers going on all the time, which is probably as bad as full time connections. -- Jeff Karl Schwamb Feb 18 1994, 11:48 am show options Newsgroups: rec.games.chess From: schw...@isi.edu (Karl Schwamb) - Find messages by this author Date: 18 Feb 1994 19:48:52 GMT Local: Fri, Feb 18 1994 11:48 am Subject: Re: "free" ICS vs. "Controled" ICS solution Reply to Author | Forward | Print | Individual Message | Show original | Report Abuse scho...@csugrad.cs.vt.edu (Jeffrey Schoenborn) writes: > >There's no reason a client program like XICS couldn't be changed > >to allow connections to multiple servers. This would allow greater > But that defeats the whole purpose of having the multiple servers; you > would have to be connected to each at the same time. You're taking a simple-minded view of this. You would *not* have to be connected to all the other servers at once. The remote servers could be checked periodically so as to not be a burden on the client process. As remote servers go up, their users are added to the list of players. As they go down, their players are removed. You could be connected to 1, 10, or more servers at any given time. You could even have user configurable limits on the number and type of connections. Splintering the chess players is not going to achieve much in my opinion. Creating a distributed environment which provides for diversity within a common setting will be a much better solution. -Karl Jonathan Segal Feb 18 1994, 1:22 pm show options Newsgroups: rec.games.chess From: jse...@icsib17.icsi.berkeley.edu (Jonathan Segal) - Find messages by this author Date: 18 Feb 1994 21:22:03 GMT Local: Fri, Feb 18 1994 1:22 pm Subject: A possible technical solution to lag (was Re: "free" ICS vs. "Controled" ICS solution) Reply to Author | Forward | Print | Individual Message | Show original | Report Abuse Here's an idea for people to mull over (and maybe for somebody to implement). This is a reasonably major design change suggestion (modeled after the okbridge system), but should be quite doable. This scheme requires an intelligent client, but since most people probably play with special clients anyway, this wouldn't be a big deal... Don't have a Chess Game Server at all. Instead, have a ratings server and game arranging server, but don't process the moves of each game through the server. Instead, when a match is agreed upon by two people, the server sends a message to each player's client, the clients then connect, and talk directly, to play the game (essentially, one of the clients will enter a mini-server mode to serve the single game). When the game ends, the result is sent to the server (maybe even with the game record for posterity's sake), and new ratings are calculated, etc. The main server could even keep track of the games being played so that if somebody wanted to observe a game, they could connect to the ICS client/ game mini-server and watch the game. This would turn lag during a game from a global problem to a purely local problem -- i.e. any backup at the server would not affect any games in progress, and the only lag during games would be due to network or computer lags between the two players of the game in question. If two players realize that they will have lag (say because they are on opposite sides of an ocean), they know either to not play, or to play with very generous time controls. In fact, such a system could be added to the current ICS setup -- suppose each player has a variable which says whether or not they have a "smart" client. When a game is started between two players who both have smart clients, the actual game play is off-loaded to one of the clients, but if one or both of the players does not have a smart client, the server will adjudicate the game just like now. These are just some ideas for people -- the current ICS administrators, and those considering starting competing servers alike -- to mull over. There are obvious and not-so-obvious enhancements to be made and problems inherent in such a system, but people can take it from there.... Comments on such a proposal are quite welcome. -- --------------------------------------------------------+ "Everything should be made as simple as possible. | -JAS But no simpler." -A.E. | Jonathan A. Segal jse...@icsi.berkeley.edu Randell Jesup Feb 18 1994, 2:15 pm show options Newsgroups: rec.games.chess From: j...@cbmvax.cbm.commodore.com (Randell Jesup) - Find messages by this author Date: 18 Feb 94 22:15:26 GMT Local: Fri, Feb 18 1994 2:15 pm Subject: Re: "free" ICS vs. "Controled" ICS solution Reply to Author | Forward | Print | Individual Message | Show original | Report Abuse b...@athena.mit.edu (David B Pecora) writes: >It has been suggested by a couple of people that a bunch of splinter ICS's >be created to fix the lag problem. As I understand it, lag is a problem with >the networks and not a function of the number of players on the server at >the time. I have experienced major lag at the euro-ics too. However, "lag" usually only exists in portions of the network. Thus, a set of ICS servers makes it more likely that one or more of them will not have lag (or will not have lag for a significant portion of the people). A fair bit of lag seems to be things happening on the server machine - I don't know what, maybe mail, maybe backups, maybe ftp, maybe compiles. The reason I say this is that during the 1-2 minute lags, I can ping ics.uoknor.edu and get 200ms response times. It's not network lag, the server is busy doing something. This isn't all lag, but it's probably a lot of the really annoying long delays. >Aside from this point, it's unclear what purpose segregating the ICS's would >serve. Just think of all the annoyances you would have: if you were playing >standard and you wanted to play blitz, you would have to disconnect and >reconnect to a different server. If you were looking for somebody, you would >have to search through maybe 10 servers before finding him or concluding that >he was not on any (and what if he connected to one after you searched it?) >This situation would be analogous to a city having several libraries, one >for nonfiction books, another for fiction, another for reference, etc., but >where books were permitted to circulate thorugh at random, and where there is >no inter-library computer link. Why not have a link? The servers could pass information on who was on between themselves, so you could see what's happening (who's on, etc) on other servers. Eventually the interface programs could be upgraded to talk to multiple servers at once - you could even switch servers in the middle of a game pretty easily. The concept of a server would become a much more nebulous and distributed thing. The server you were using is where your moves and (maybe) keystrokes are being processed. Talking might be distributed as well, though it's not necessary. The added load to the network/ server is minimal. Also, a lot of load could be taken off servers by allowing front-end programs to really act as full front ends, instead of doing single-character editing (telnet) over the net. This would cut both server and net load. The servers would still accept ASCII connections (for current clients or people without a front-end), but you might not get some of the new features (like dealing with multiple hosts transparently). The netrek world dealt with this in an ad-hoc method by having a clearinghouse ("metaserver") that would report on how many people (and who) are playing on each server all over the world. It made finding players/games very easy. If you're tempted to re-invent ICS, don't recreate it's design flaws. Make something better. -- GNU Emacs is a LISP operating system disguised as a word processor. - Doug Mohney, in comp.arch Randell Jesup, OS Group Head, Commodore Engineering. j...@commodore.com (preferred) or rutgers!cbmvax!jesup Disclaimer: Nothing I say is anything other than my personal opinion. Jeffrey Schoenborn Feb 19 1994, 9:35 am show options Newsgroups: rec.games.chess From: jscho...@csugrad.cs.vt.edu (Jeffrey Schoenborn) - Find messages by this author Date: 19 Feb 1994 12:35:08 -0500 Local: Sat, Feb 19 1994 9:35 am Subject: Re: "free" ICS vs. "Controled" ICS solution Reply to Author | Forward | Print | Individual Message | Show original | Report Abuse j...@cbmvax.cbm.commodore.com (Randell Jesup) writes: >b...@athena.mit.edu (David B Pecora) writes: >>It has been suggested by a couple of people that a bunch of splinter ICS's >>be created to fix the lag problem. As I understand it, lag is a problem with >>the networks and not a function of the number of players on the server at >>the time. I have experienced major lag at the euro-ics too. > However, "lag" usually only exists in portions of the network. Thus, > A fair bit of lag seems to be things happening on the server machine - >I don't know what, maybe mail, maybe backups, maybe ftp, maybe compiles. >The reason I say this is that during the 1-2 minute lags, I can ping >ics.uoknor.edu and get 200ms response times. It's not network lag, the server >is busy doing something. This isn't all lag, but it's probably a lot of the Is 200 ms bad? I have a very bad internet connection; when I get 200 ms ping time to a non-local host, I consider that great. Even then, I would contend that 1/5 of a second isn't going to make taht much difference to the play of any of us. For me, the great majority of lag is local; my machine is usually one of 50 or so SLIP connections through the same system. A few times in the last few days, I have had some serious, definitely non-local lag. Perhaps a good idea would be to disable the instantaneous automail. I don't know how much disk space this would take, but if games were mailed out at non-peak hours, this would probably cut down on the lag. It would also be pretty easy to set it up so that games are mailed immediatly only by request of the user; and the rest of teh "automail" games were sent out later. -- Jeff Schoenborn j...@orthanc.async.vt.edu Tim Mann Feb 19 1994, 1:01 pm show options Newsgroups: rec.games.chess From: m...@src.dec.com (Tim Mann) - Find messages by this author Date: 19 Feb 1994 21:01:16 GMT Local: Sat, Feb 19 1994 1:01 pm Subject: Netlag Reply to Author | Forward | Print | Individual Message | Show original | Report Abuse "Netlag" as experienced on ICS is usually caused by lost packets, not by long packet round-trip times. That is, although most packets may get through in 200ms, some percentage of packets don't get through at all---they are discarded somewhere along the way because a router ran out of processing capacity, because the next network link ran out of bandwidth and the queue of packets waiting to go out on it got too long, because electrical noise damaged some packets, or the like. When a packet does not get through, it takes some time for the host that sent it (either yours or the ICS) to notice that it hasn't been acknowledged and decide to send it again. If packets are not lost often, a TCP implementation will generally retransmit quickly, assuming the loss was an isolated event. If packets are lost often, a TCP implementation will generally throttle back its retransmission rate, on the assumption that the network is already congested and frequent retransmissions will only make things worse for everyone. When I see netlag on the ICS these days, running "/etc/ping -l" for 20 seconds or so usually shows me that roundtrip times for packets are only about 200ms, but perhaps 25% or more of the packets are lost. This loss rate is enough to cause severe delays in TCP response. Sometimes I see a 100% loss rate for a while. This is obviously going to cause a delay in response until it corrects itself. (You can check on this yourself, but PLEASE DO NOT RUN PING FOR LONG PERIODS OF TIME. It adds to the load on the network and can thus make problems worse.) It is also possible, of course, for "lag" to be caused by slow response on the ICS host itself. When the ICS was on rafael, we had problems for a while where running the mail program to send out game scores would take memory away from the server and cause it to page to disk, resulting in a hiccup in response times for all the users. It took us quite a while to realize what was happening. Surf fixed this problem by killing off some other programs that were running on rafael, making more real memory available. What I've seen by running ping convinces me that the current round of lag problems are due to the network, however. The Internet is very large, growing, and changing. Various parts are being upgraded all the time. Sparky says that a slow link and some outdated routers on the path between uoknor and the main part of the Internet are due to be upgraded soon. This may improve the current lag situation for most people. On the other hand, in the last few days I've often heard people shouting "lag" when I didn't have any, which suggests problems in different parts of the network. Ten or twelve years ago, when I was a grad student, the Internet was so overloaded that it was useless for telnet. Mail worked acceptably, and it was possible to ftp files by breaking them up into small pieces and being very patient. A chess server would have been unthinkable, except perhaps for postal games. This was the view from Stanford, one of the better connected sites. Since then, the network has been massively upgraded and works much better. But it's also been expanding at a tremendous rate. I expect plenty of glitches and periods of overload as it continues to grow. --Tim Mann (admin Milwaukee on ICS)