TrialBid

Um, actually may refer to a problem that I've already reported. In the flash version, activities that seemingly should reset the timeout clock obviously do not. If I have only been doing things like browsing and refreshing the list of coming tournaments the timeout warning will pop up right as I am doing those things. Since you do not have a long time from see the prompt until it cancels your session, you may therefore get disconnected when you don't expect to be: You were chatting in an untimed game and it looks like it's going to be a while. You say brb to get coffee, answer nature's call, or whatever, and you are mysteriously disconnected when you come back 2 minutes later. The prompt appeared but you didn't see it.

I dare say this line of inquiry is related to another theme that comes up often in the Best Hand money games: Ideally we could claim just as we do now. Failing that an easy-to-implement test that would auto-claim when there is no longer any way to lose a trick. "My hand is all high" ought to be trivial to test for. And if even that challenges the programmers unduly, then let us concede the rest of the tricks--with or without the test refinement suggested in this thread.

Certainly starting more games more often may partly address the issue. It doesn't take into account the fluctuating demand, however. Why not add the "start when full" feature to make more games only when demand surges? That way you won't have to revisit constantly the question: is this the right frequency? Late night the numbers playing Robot Duplicate seem just about right. With more frequent games then, fewer players in each, I'd enjoy it less.

I agree that Speedballs can't accept latecomers. However, how about the Individuals and slow pair games? Maybe a holding tank of late entrants that will be allowed into the game whenever a full table is made during the first 5 minutes or so? That could also be a revenue enhancer: give people a chance to buy the Sitout spaces before filling them. And there's no reason why anyone should be denied late entry to any of the Robot games. Again, it's just turning down money if you don't let folks in.

The 25 cent 8-board duplicate is like a chocolate-drop candy, addictively fun, not too big to spoil your dinner. It also seems to be really popular. I note that the current limit of 48 gets pushed during some hours of the day. So why not not have a more modest limit and state that the game will start in 5 minutes or when full whichever comes first? As soon as one starts, queue up another to start in 5 minutes. For me, I'd rather play in a game just big enough to be able to have a chance at that .80 BBO Masterpoint. Others might feel similarly. But most importantly, it gives more of us quicker gratification and, I bet, would make the game even more popular.

I believe that the Free Robot Duplicate (IMPS) is NOT limited to once per 24 hours (unless it has recently changed) and never has been. The older Free Robot Race still limits you as it has almost from the beginning. It might be a thread for another forum that it is virtually impossible to play in either game when using the Flash interface because of the necessity to refresh the Tournaments list at exactly the right second for a Free tournament to be shown before it is filled up.

Fred, I'm hoping you are back safely and ready to have at your projects once more. I trust you won't be annoyed that I quote myself from Feb 20th. Perhaps my ideas seem wrong for some reason but I thought these points were especially important and the first idea seemed like an obvious no-brainer choice. Since you didn't specifically respond to these I'm offering them again. Would this work?: Use the ctrl-click function that is frequently used for selecting multiple items. The web client comes up with the Friends tab highlighted. Ctrl-click Stars and it is additive. Stars are shown with Friends and both tabs are highlighted. If the tab is already highlighted, ctrl-click is subtractive. That's the sort of hidden trick that doesn't complicate anything for the neophyte. I hope that you are being ruthlessly honest here in tracking exactly how much bandwidth each function uses and what that amounts to as a percentage of server loads. The fact that your operation is robust enough to keep going generally when many Windows clients reset and demand enormous loads to log in again tells me you are not starved for bandwidth. In a client server environment, there has been a long history of blaming slow transactions on network latency and/or congestion when, in fact, the underlying cause is that specific server tasks have been given the wrong priority or are resulting in disk accesses when they should be memory resident. I can only guess at some of the tricks that Google uses in its search bar--as you type it offers a list of likely search completions from the cloud and does it with keystroke-level real-time feedback. For that to work, they must have high-priority, memory-resident (and doubtlessly brilliantly and cleverly optimized) code. To be sure, I'm sure it uses a lot of bandwidth, but they are able to provide it for millions more users than you are ever likely to have. To put it more succinctly, don't overvalue small savings that impact the users' experience adversely especially while you are still trying to convert us away from the Windows client that is so very costly in bandwidth for so many reasons. A particular application of the principle here that seems important to me is the presentation of pending tournaments. Currently you present "Interesting tables" as Join(19). That means you have the code in one place that could help users who want to know the participation level of MBTs, Individuals, etc., if you just show the number of entrants so far in the same way.

A few more items: - Why must I hover over the entries in a tournament to see their rank? The cost is far greater in user aggravation that the tiny extra data sent to display it in the first place. - when a tournament finishes we are returned to the opening screen. The old environment where there is a completed tournament page with easy access to standings, etc., seemed intuitive and the new way much less so. - the GIB built-in analysis is a great tool for helping to settle arguments and is generally useful and fun. Is that likely to make a reappearance in the Flash version? - It is confusing to have two places to look when I'm chatting to someone. If their profile came up, then it seems to want to chat from the profile box. I'm discovering that just as I started to get used to the chat line to be at the bottom of the window. - My preference would be to get rid of the theater-style fades in-and-out of messages, boxes, etc. Pop something up and get rid of it as close to instantly as possible. Yeah, that's probably something there needs to be a setting for because some love cool effects.

I've studied this a bit more and can offer some additional insight. Whether this is a bug may be a matter of debate, but I do not think it works optimally. This afternoon I watched the following: - I signed on at 1:28 - I selected "Show all tables" and then tournaments at 1:29 - I selected running tournaments at 1:38 - A message box to stay logged on appeared 2:23, disappeared a few seconds later. Shouldn't this prompt stay until I reply? (I didn't reply.) - I changed to pending tournaments at 2:25 - I was logged off at 2:33 Unfortunately I did not see the message box that appears for a few seconds after the logoff. However, what is very clear is that there are actions I can perform that do NOT reset the timeout function. Why should any actions I perform that interact with BBO be excluded from resetting the timeout?

Would this work?: Use the ctrl-click function that is frequently used for selecting multiple items. The web client comes up with the Friends tab highlighted. Ctrl-click Stars and it is additive. Stars are shown with Friends and both tabs are highlighted. If the tab is already highlighted, ctrl-click is subtractive. That's the sort of hidden trick that doesn't complicate anything for the neophyte. I hope that you are being ruthlessly honest here in tracking exactly how much bandwidth each function uses and what that amounts to as a percentage of server loads. The fact that your operation is robust enough to keep going generally when many Windows clients reset and demand enormous loads to log in again tells me you are not starved for bandwidth. In a client server environment, there has been a long history of blaming slow transactions on network latency and/or congestion when, in fact, the underlying cause is that specific server tasks have been given the wrong priority or are resulting in disk accesses when they should be memory resident. I can only guess at some of the tricks that Google uses in its search bar--as you type it offers a list of likely search completions from the cloud and does it with keystroke-level real-time feedback. For that to work, they must have high-priority, memory-resident (and doubtlessly brilliantly and cleverly optimized) code. To be sure, I'm sure it uses a lot of bandwidth, but they are able to provide it for millions more users than you are ever likely to have. To put it more succinctly, don't overvalue small savings that impact the users' experience adversely especially while you are still trying to convert us away from the Windows client that is so very costly in bandwidth for so many reasons. Did the message you received explicitly say you were timed out? There are other ways a connection can be lost (a hiccup somewhere on the Internet is the most common reason). If it was a timeout then it sounds like a bug. If you can confirm this I will investigate. Now that you mention it, I saw no message. When I got back to that window, it simply showed the login pane. Perhaps a good idea is to offer an information box above or below the login pane stating why a session that was opened was terminated. If it showed a timeout screen or error screen that then was replaced by the login, that's not helpful unless I was sitting there watching. EDIT: I just saw what can happen by watching the web screen and logging in the Windows client. There is a box that appears below saying "Connection closed: unknown2" (Cryptic, but it's something.) However, the box is cleared after a few seconds. Why? I'm guessing it was a default action that no one was aware of or didn't see the reason to override.

I've been a slow adopter of the web client for a number of reasons. Yet it is something that I really do want to see succeed because of the technical superiority of what goes on under the hood. Whenever there was even a slight hiccup in connectivity, the Windows version (requiring full TCP/IP sync of all state information even at the expense of keeping actual play going) cost a lot in bandwidth and user frustration. Here's a grab bag of items that seem problematic to me still: - I can no longer see the set of online players of interest to me listed together. I prefer to select Hosts, Stars, and Friends. Now I must choose to see one group at a time. - The single screen doesn't allow viewing disparate things together that I previously could. Because you accommodate the smallest screens in use, those of us with abundant screen real estate (like my dual 1680x1050 monitors) can no longer have the Movie view and the Convention card parked elsewhere while we still see who's online or what tourneys are coming, etc. How about making many if not all of the view panes detachable? - I value a permanent, automatic record of all hands I have played--including MBTs and Robot Races. There is always a security concern when remote software gets to write locally, but, perhaps a small optional client to install locally could handle this. Are you aware, by the way, that this function is now broken in the Windows client when playing a MBT that goes over 16 hands? The remaining hands are not recorded--or rather perhaps they overlay the hands starting from 1 again. It's confusing to look at one of these corrupt files. - Convention cards do not go seamlessly from one environment to another. The web client allows more space, but the "..." drill-down information that the Windows client shows does not transfer. I'm sure this has been an issue from time to time in real tournaments as to who had declared what for their agreements. - The web-client profile truncates the name of a tournament someone is playing in or kibitzing. Learning that a player is "Playing Tourney #1382 (mag" isn't as helpful knowing the full tournament name and table number. This is even more confusing because the #nnn doesn't always match the number as given by the Tournaments in progress. Currently someone is "Playing Tourney #326 (BBO" while the actual tournament is listed as "#9 BBOLAND 19 - 28 FEBRUARY WEEK - 100 $ tournament" - Why is there a time-out on the profile information that is raised via a hover-over? The instant feedback you get in the Windows program never goes away until the mouse is moved away and that is the way I think it ought to be. - I cannot see via a hover-over how many people are registered for a tournament I might be interested in playing in. This is a pain, because I rarely play the Robot Race, for example, unless I see 10 or more signed up--which doesn't happen often. Offering expanded status information that would show number signed up as well as minutes to start might be close enough--especially if the list were updated every 10 seconds or so instead of the longer interval that appears to be the case now. - Note that in the existing web client, a user is virtually certain to be shut out of Free MBTs. It appears to me that new tournaments are not added to the list in the refresh the client does. You must take a positive action to reload the list. So unless you load the list at exactly the right moment you will find 10 people will have signed up already. - I have recorded the following link http://www.bridgebase.com/client/client.php as the way to start the client because I do not like having software open windows unless I want them to. Because I want to work this way and you have specifically asked that people use the link on http://www.bridgebase.com/ that opens a new window, I must check there periodically to make sure you are invoking the client in the same way. At least pledge that the link as I have recorded it will stop working if it becomes out of date. - EDIT: I'm adding this a few minutes later than the original post to note an oddity. While composing this note. I had the web client open. I never went to anywhere to play. I just looked at lists of tournaments and players. Somehow, I appear to have been timed out--even though my previous interaction had been only 3-5 minutes earlier. Is there an inadequate list of actions taken while using the client that actually cause the timeout logic to reset? I cannot otherwise explain how I was bounced so soon after interacting. I don't know whether any of this is new to you. And I'm sure that I will never abandon BBO because it is the greatest Bridge place on earth. But I want you to know how I'm experiencing your new efforts.

I chatted with Uday last night and he said he understood more or less why this happened, that it is not common, and he plans to fix it in a future maintenance release.

After all 10 boards of team game #1678 complete and were scored and were visible in the Movie, the above error was reported. BBO HELP insisted that somehow the team setup or the host could have CAUSED this error. I'm sorry, but that doesn't wash. There is a bug here of some kind. Even if it is only a bug in reporting.

More than once I've asked Vugraph commentators if it is possible to record an irregularity that occurs at the table. Today, when a lead out of turn was condoned, I now gather that the answer is no! Such things are part and parcel of the live game of Bridge and belong in the record!

Pijler asks for clarification of "virtual desktop" Wine has two ways of windowing an application: 1- Each window created by the application is created as an X11 window, or 2- One X11 window is created for all wine windows to exist in. This is the virtual desktop. In the standard wine configuration, a program called winecfg is included. Run it and you can control which way wine runs by default and/or for any specific apps. You can define a standard size like 800x600 (the smallest that BBO will usefully run in) or 1024x768 or create a custom size, well-suited to fit inside your existing setup. On my 1280x1024 I've used 1024x960 for example. BBO doesn't seem to mind odd sizes and picks its largest window layout that fits in the bounding rectangle. Also winecfg is where you control the Windows version that wine is emulating, again, as a default and/or for specifically named apps. I recommend Win98 for BBO. I hope this helps.

The fact that so many people overrate themselves is a chronic problem that does interfere deciding when to play with someone you do not know. I'd like to see this stay on the radar unless and until some solutions are actually tried and rejected. Naturally, I have my own pet system to propose! :) 1- Each player's rating is clickable and you can vote it +,-,=. If you vote again, it updates and replaces your previous vote. 2- Based on the standard deviation of the agreement assessment, you get next to your own evaluation a + or ++ if you underestimate yourself or - or -- if you overstate. 3- The ratings given at your self-selected level are remembered so that if you judge yourself Advanced and you get -- you cannot change your rating to something else and have it reset to = when you set it back to Advanced. 4- The ratings given should be aged. Nothing reported more than 1 year ago should count. Something like this could also help deal with the insidious strategy a few players use to claim Novice or Beginner status (often only temporarily) in the hope of getting a good opponent to get too frisky. And if you don't want others to judge you? Set your level to private--with all the negatives that projects to others.

It is easy to understand the frustration behind this line of inquiry. Is there some kind of strategy that would stay cheat-proof without creating a radically different game? I'm not entirely sure. 20HCP to a side is cheat-proof but is a very strange game. There've been some all 10pt hands goulash tourneys on BBO, for example, that really weird me out. Here's a strategy that might be good enough: - Everyone's first deal is random. - From the 2nd deal forward, over a moving window of, say, up to five deals, your side's point expectation would be boosted or diminished by the previous hands. If it is a log type of weighting, hands of all possible values could occur on any deal, only the relative likelihoods based on HCP expectation would change. - If you've done badly with good cards, you'd be worse off than you are now. But that sounds OK to me. - If you have had a run of bad cards, you'd have greater hope of a couple of good hands to offset your losses. There are two things, though, that would help the MBT experience a lot that might be easier to implement: 1- Have longer MBTs. More hands, the luck evens out. Has to be trivial to implement. 2- When you and your GIB win the declaration, the human will always declare. Why would that be hard? I've corresponded with Fred a few times about GIB in MBTs and I've repeatedly been assured that the declaration improvement will eventually come. That is so obvious a need for a true test of skill. Moreover, it will take some of the CPU load off BBO servers--a resource I hear frequently cited as crucial for delivering the GIB-based services. When Fred comes back victorious from the Team Trials :), perhaps MBTs will get another look.

By the numbers, I am miserably old-fashioned and out-of-touch. However, there is simply no room for 5NT to be anything other than GSF, imho. The real rub comes down to this: with the 3C bidder still relatively unlimited, there can be no possible justification for using up all that bidding room, unless a grand slam can be underwritten simply on the grounds of knowing whether partner has particular values and that if he doesn't a grand slam is out of the question. To me 5NT makes sense as pick a slam when the auction has progressed farther and neither partner has been able to imply more than a secondary preference for a suit. Why wasn't 5NT bid on the previous round? Since partner might be rebidding 2C on Jxxx, why risk his having that hand when you can hear one more clarifying bid first? Perhaps I have AKQJxxx AKx -- Kxx. There is no slam at all opposite x Jxx AKQ10x Jxxx unless I get a helpful lead.

It's not obvious to me what is going on. You may want to run winecfg and experiment with which version of Windows wine is acting as. I have NetBridgeVu.exe set to run as a Windows98 app. The general rule is that wine has fewer bugs emulating the earlier, simpler Windows versions. So if the package you're using doesn't require a later version's features, don't enable them! You might also experiment with having wine load BBO in a virtual desktop. Its interface with X is somewhat simpler than the default. There have been times that I've suspected a memory leak in either BBO or in wine. You might consider running the program from the command line via something like: ulimit -m 59216 && wine "C:\Bridge Base Online\NetBridgeVu.exe" If problems develop quicker, the smaller you make the number, the more likely a memory leak is to blame.

Apologies to Fred and Inquiry, somehow I missed Fred's post in replying to the later one. I noted an edit in the post where I made my error. Perhaps. Are you aware that the normal operation of a browser, even on dial-up, opens many sessions to get a page with numerous graphics, frames, etc? Using TCP for http sessions is probably the most successful use of TCP/IP sessions. Certainly it is what everyone sees who uses the web and what everyone would find unacceptable if it were run through a single session. (The technical-minded will know that it is typically a number of sessions that are opened and requests go to the session that gets free first so as to avoid the overhead of opening new sessions while a page is loading.) A single TCP session being preserved over an extended period of time, to carry both high- and low-priority information, is definitely problematic. All the more so on the Eastern European ISPs that jtfanclub mentioned.

Very well. We'll assume for purposes of our discussion that you actually do know something. I didn't ask you to configure my mail server but I'd be happy to put my resume up against yours any day. You do reference a key part of the debate that may come up if we ever get to things that matter. [i failed to see Fred's post, so the comment here made no sense and I deleted/edited it.] With TCP connections, to protect play there should be a minimum of two session per client, one to carry the state of the hand in play and another carry all the nonessential stuff. The QoS for play should then be set to real-time and the rest can be set to minimum cost. That to me sounds like exactly the justification for getting BBO out of the TCP business if that is where it is. Those extra messages BBO and its clients send waste the bandwidth that uday wants to preserve AND the TCP layer is preventing the application from knowing about trouble in a timely fashion. Much of the work with streaming media (see helixcommunity.org for example) is already working with both TCP and UDP, with UDP being the choice that works better more often. BBO's server and every BBO user pay part of the price when disconnections occur. Doesn't it just make good business sense to work to minimize them?

:) This thread finally seems to be getting some traction! Inasmuch as I run a tiny ISP, I really do know whereof I speak. Uday, I'm just trying to get the facts out here and I'm glad you are not offended. At the packet level, your message is dispatched on a best-effort basis. But anywhere along the way, if congestion occurs, a transient glitch in hardware, anything, your packet may be silently dropped. So the question comes up about that lower-level code anyway and it needn't be a question of bugs, per se. I can be sure of is that there is not an end-to-end acknowledgment of each message before the next message is sent. There is too much packet latency (ping-time if you will) between even fast well-connected machines to wait out each message for confirmation. So BBO sends many packets at once and the client must parse them to see what is missing. As soon as packets are detected as lost, some kind of recovery effort must begin. What I'm saying is that it is clear to me that the recovery efforts currently in place could be substantially improved. Here are some ideas: Make sure that the lower-level code, in fact, immediately detects a missing packet and informs the client of an incomplete message. When an incomplete message is detect, the client should light the red dot on the user's name, just as the server obviously orders up the light for other users with problems to be displayed on my screen. Separate play messages from all others and insure their delivery first. What I'd be interested in seeing quantified is the amount of traffic BBO must process in doing a connection from scratch compared to the amount of traffic associated with sessions that are already established. My guess is, given the relatively long setup time (especially when 10000+ players are on) at the beginning, that it is a very significant part of your load. So, I see this discussion as ultimately pointing toward a win-win solution. You can reduce your bandwidth consumption because users with transient problems are saved a full "Connection lost ... reconnecting" cycle and the players get to continue their games.

That doesn't appear to fit situations I've seen repeatedly. (A common instance is where I continue to get chat messages right up to the point that I go through a "connection lost, reconnecting" cycle.) Moreover, it isn't the way the Internet works. It takes some kind of elaborate session protocol of the kind I described to make up for packets that may be dropped at any point along the way. Without a more detailed explanation of how that supposedly works with BBO, I can only infer that it is a popular notion of how somebody thinks it is supposed to work but doesn't.

That doesn't appear to fit situations I've seen repeatedly. (A common instance is where I continue to get chat messages right up to the point that I go through a "connection lost, reconnecting" cycle.) Moreover, it isn't the way the Internet works. It takes some kind of elaborate session protocol of the kind I described to make up for packets that may be dropped at any point along the way. Without a more detailed explanation of how that supposedly works with BBO, I can only infer that it is a popular notion of how somebody thinks it is supposed to work but doesn't.

Uday, thanks for the comments. The reason that I placed this thread in the "Suggestions for the Software" forum is that all of the things you suggest are sometimes not enough. These in particular seem insufficient. The easiest way to do better that I see would be to attach, say, a serial byte for each message to and from the server. If the client sees serial 86 and serial 85 is missing, then instantly it will know that it could have missed something important, like the play of a card from dummy and it can notify the server of the missing message. Ditto, for the server, if a serial entry is skipped, it can immediately request that the missing action be resent. A small field, like a byte, is probably plenty big enough. Cycle from 0 to 255 then wrap around. Yes, theoretically a block of 256 messages could be missed and go undetected. In that case we'd be no worse off than we are today. Even though this process adds a tiny overhead, I'm guessing it could save BBO bandwidth overall. It appears to me that losing the connection and reconnecting actually represents a pretty substantial chunk of bytes that might be avoided more often. I mentioned priority in the first post because if it is discovered that several messages are missing, it is most important to get those messages resent that affect the state of play of a hand. The chat, players, counts, tables, etc., can wait.