[Chamaco]

I do not know the details of the BBO code implementation and problems.

However, here is my view on scaling:
I like the idea of having on a separate server the activities external to the "Main LobbY".

So, basically, moving to separate servers:
- the Vugraph Broadcasts,
- all the Tourneys
- Team Matches
- Private Club Activities
- Partnership Bidding
- Access to Library
- Online BB Sample products.

BUT, my personal wish is that the Main Lobby stays as a single BBO.

As far as i can see, for example in this moment, out of a total of 5200 players logged in, only 1700 are in the main lobby, about 80s are in Clubs,
and about 1950 in the tourney/team matches.
The remaining are in the "explore bridge" section (Chat/Pship bidding, etc).

So, if we consider this 1/3 ratio of people in the main lobby vs total logged, even if the case 10000 of total BBO member logged in, theat would mean about 3300 players in the main lobby, which I guess (maybe wrongly?) that would be manageable ?

Just my 2 cents :-)

[cherdano]

Hi Fred,

I would like to add one more comment. In the potential setup described by you at the beginning of this thread, it seems to me that the only things I do not get from BBO2 when logged into BBO1 are the following:

• Full player list
  
• Full Main Bridge Club table list
  
• Lobby Chat

However, in my view all of them are unneeded anyway (of the first two, most people only need friends, star players, and open tables), and this seems to be almost a consensus according to my reading of the posts in the two threads. (Exception: Organizing team matches currently pretty much needs Lobby Chat, this would need a solution; an easier way to setup team matches would be really nice, anyway.)

If that is right, you could just disable all of them, and then there would be almost no user visible difference between the current setup, and a server-split into several servers.

Best,
Arend

[fred]

QuiteACard, on Mar 25 2005, 09:52 PM, said:

fred, on Mar 25 2005, 02:34 PM, said:

QuiteACard, on Mar 25 2005, 07:16 PM, said:

Would it be that difficult to start to move some of the services (e.g. vugraph, "Explore Bridge", the private clubs) to separate physical servers without the players even knowing about it?

I would not be very difficult at all, but it would have a negibable impact on the problems we are going to have if our numbers continue to grow.

Fred Gitelman
Bridge Base Inc.
www.bridgebase.com

Is it fair to ask which resources are the limiting factor to BBO's growth as it exists today? I have reviewed the thread Scaling, Opinions/ideas solicited but there's not too much technical detail provided. In general is system growth constrained due to limitations regarding memory, processor, IO, network communication, or something else?

I understand this is an easy question to ask and almost impossible to answer definitively but I'm just trying to get a feel for the situation.

The general nature of the problem is that, given the way BBO is now, every time any one of the following events happens we need to notify everyone on the system:

1) A person logs in
2) A person logs out
3) A person changes his profile
4) A person goes into or out of brb mode
5) A table is created
6) Table options are set/changed
7) A person joins or leaves a seat
8) A table is destroyed
9) A lobby chat message is sent out
10) A tournament is created
11) A tournemant's is edited or its status changes
12) No doubt several other things I have not thought of

With 5000 people logged in some of these things happen no more than once every second or 2, but some of these things happen dozens of times every second.

The total number of such messages that has to be sent out increases quadradically (sorry to the math people out there if this is the wrong word) as a function of the number of people logged in.

This is a problem because:

A) Computers, like people, can only do so much processing in a given amount of time. Eventually our poor server computer's CPU resources will become bogged down and be unable to handle the load. I actually find it remarkable that our server (which is just a PC) can handle as many simultaneous connections as it does now (3 cheers for Uday and Intel!).

The wire that leaves our server computer has a maximum capacity (in terms of bits/second). We will eventually exceed this capacity. Yes, we could get a thicker wire, but that would be expensive and would not solve the other problems.

C) The wire that enters your PC has a maximum capacity (in terms of bits/second). Dialup users will eventually be unable to swallow all of the data we are trying to shove down their throats.

D) Even if we get past A), , and C), the client program still has to be able to process all the data and do all the other things it does (some of which, like drawing the screen and responding to mouse movements to say nothing of "serious operations" like clicking the DF button, can be computationally expensive).

Of these problems A) is our most serious concern. is our next most serious concern. C) could become an issue one day. As far as we can tell D) is unlikely to ever be a real problem (but we still want the client to be able to behave without any apparent "sluggishness").

Moving things like requests for Bridge Library articles to a different server will not make any real difference, because such requests are relatively infrequent and the server response to such requests is sent to only 1 person (as opposed to everyone who is online).

Hope that helps.

Fred Gitelman
Bridge Base Inc.
www.bridgebase.com

[DrTodd13]

Quote

OKBridge used to (and maybe still does) rely of each table host's computer to be responsible for relying all table-related messages to all clients who are playing or kibitzing at that table. There are some problems with this approach:

- If the table host has a poor connection or slow PC then everyone at the table suffers

So do something smarter. The table server doesn't have to be the table host. You could find the person at the table with the most reliable computer and then let them serve the table. I realize moving this function to clients would be hard work but you could just as easily have more computers onsite that handles serving tables. This seems completely distributable. Just have these servers request a new hand and then report the result back to the master server. All the table chat and play of each card could go through these servers.

Quote

- There is a limit  to the number of kibitzers who can join a table

Again, do something smarter. If you were to choose a client to host a table then pick the client that has broadband and if none of them have broadband then kick the table hosting responsibilities back to a BBO server.

Quote

- If the table host leaves, the table closes (you could get around this by writing additional code, but it would probably be a lot of difficult work)

It wouldn't be easy but I don't think it is something so difficult it couldn't be done. No rule says the table has to shut because the table host leaves. That is just a decision OKB made because it was easy.

Quote

So as far as I am concerned, any solution that involves depending on our clients to act as "table servers" is a non-starter.

All I'm saying is that it is an option that shouldn't be rejected out-of-hand. The problems are surmountable and in the end it is a much more scalable solution.

Quote

I personally don't think "constantly in synch" is necessary, but it is certainly desirable in some areas. For example, if you are looking at a list of table in the hope of finding a place to play and if the list doesn't update itself automatically, you will frequently try to sit in an empty seat that has since been filled.

I would find this preferable to what happens now, which is that I can't figure out where to play because the list is changing too frequently. There are some options here. One is a refresh button. The other is allow the user to specify an automatic refresh interval. Every X seconds the client automatically requests a refresh. Another possibility is that when the client is actively looking at tables the server automatically sends updates. At least this way, if you weren't looking at the table list then the client wouldn't need to be processing updates to table...neither would the server for that matter.

Quote

Furthermore, having to click a "refresh" button constantly is a big pain. People with slow connections would also suffer every time they went to into the Main Bridge Club (or clicked the "Tables" button) because they would have to wait for the table list to download. The bigger BBO gets the bigger these problems get.

When I was on OKB, I never minded the refresh button. The relevant table data should be so small anyway that even slow connections it doesn't matter. Inevitably, sending big messages is going to be more scalable than sending lots of little messages. The more you can collapse small messages into big messages the better off you'll be.

Quote

Surely have a quality connection is more important for almost anyone than which specific 500 tables appear in their Main Bridge Club list.

If I see one friend is on BBO1 and another friend is on BBO2, how do we get together and play? If it isn't transparent it is going to be annoying. I suspect this isn't the case for novice through adv tables but it can still be difficult to find a good expert pick-up game and splitting these people between more than one server will make the situation more difficult.

[hotShot]

fred, on Mar 25 2005, 10:16 PM, said:

1) A person logs in
2) A person logs out
3) A person changes his profile
4) A person goes into or out of brb mode
5) A table is created
6) Table options are set/changed
7) A person joins or leaves a seat
8) A table is destroyed
9) A lobby chat message is sent out
10) A tournament is created
11) A tournemant's is edited or its status changes
12) No doubt several other things I have not thought of

I don't think it would make much of a difference to me if you changed that to:
1) A friend logs in
2) A friend logs out
3) A friend/ someone playing/(kibbing) at my table changes his profile
4) A friend/ someone playing/(kibbing) at my table changes brb mode
5) See that a table is created only if i activate a table view
6) see 5
7) only if it's my table or i view the table list
8) see 5
9) Do you mean chat to Lobby (all), i don't need that i have lobby chat turned off
But it might make sence to create a team match chat room (smaller group)
10) Only need that information when i activate a tourney list view
11) see 10 or if i am registered or put myself on the partnership desk
12) Lets deal with them when they come up.

Worst thing that could happen is that it takes a few (milli)seconds, if i enter the table/tourney list, but I'm doing nothing else then.

Does your ISP support broadcasts on IP level? You create a "broadcast IP-number" at your ISP's router, that represents e.g. all IP-numbers of kibs at a vugraph match. If you send the data to this "broadcast IP-number" at your ISP's he will distribute the message to all clients in the IP-list defined before. Save bandwidth between you and your isp, but your isp will charge the full outgoing traffic of cause.

[hrothgar]

A quadratic equation takes the general form A*(X^2) + B(X) + C =0, with A not equal to zero.

From the brief description that you are providing it appears that:

The number of updates being generated is a function of the number of systems that "generate" updates and the number of systems that need to receive updates.

It is very reasonable to assume that this would result in "load" being a quadratic function of the number of end users. However, as you've noted this can produce a number of problems. Most notably there is some boundary point at which a relatively small increase in the number of end users can produce horrific effects on the total system load.

There are three "classic" solutions to this type of problem, both of which are being explored in these threads.

1.Parallelize the system, ensuring that none of the sub-components ever approaches critical mass. (Equally significantly, some care must be given to ensure that failures can't “cascade” across sub-components)
2.Architecture the system with sufficient resource that the load never approaches the boundary condition.
3.Architect the system such that the load is no longer a quadratic function.

Normally, I have a strong bias in favor of massive parallel architectures. All other things being equally, I'd much rather have a system designed with 10 small, independent systems rather than one large devices. With this said and done, from my perspective, the network effects are sufficiently important that I would prefer to explore a combination of solution 2 and 3...

First things first: I just logged into BBO. There are approximately 4560 people connected at this point in time. Of these, I only “care” about the location of 15 individuals (I have 8 friends who are logged on. In theory, I might want to know where the 7 yellows are located) Equally significant, only 48 of those 4560 people can be displayed on my screen at any given point in time. I'd guess that you can realize enormous load savings with minimal impact on end users simply by redesigning the main lobby.

In the past, I've argued that the main lobby doesn't serve any real purpose. From my perspective, life would be much easier if the main lobby were partitioned into a series of specialized lobby, each of which is specialized for a different purpose:

1. Lobby 1 is similar in nature to the current main lobby, however, it only provides me with a listing of my friends and “Stars”. While the load created by lobby 1 is still a quadratic, is a much “friendlier” one.
2. Lobby 2 allows me to quickly find a partner or a table at which I can play bridge
3. Lobby 3 supports the “Bottoms-up” matching system for teams games
4. Lobby 4 supports Vugraphs

Please note: I'm not suggesting that the lobbies that I am describing are either necessary or sufficient. I'm merely providing them as illustrations regarding what could be done. However, I do believe that starting with a task based analysis is an absolute requirement:

Consider your end users and try to define the set of tasks that they commonly perform:

1. End users need an easy method to find tables where they can watch
2. End users need an easy way to find partners
3. End users need an easy way to find their friends
4. End users need to understand what tournaments are being offered

Once you understand the task, make it as easy as possible for folks to accomplish them... From my perspective, the main lobby is more of a "default" than a solution to any real problem.

[DrTodd13]

hotShot, on Mar 25 2005, 02:43 PM, said:

fred, on Mar 25 2005, 10:16 PM, said:

1) A person logs in
2) A person logs out
3) A person changes his profile
4) A person goes into or out of brb mode
5) A table is created
6) Table options are set/changed
7) A person joins or leaves a seat
8) A table is destroyed
9) A lobby chat message is sent out
10) A tournament is created
11) A tournemant's is edited or its status changes
12) No doubt several other things I have not thought of

I don't think it would make much of a difference to me if you changed that to:
1) A friend logs in
2) A friend logs out
3) A friend/ someone playing/(kibbing) at my table changes his profile
4) A friend/ someone playing/(kibbing) at my table changes brb mode
5) See that a table is created only if i activate a table view
6) see 5
7) only if it's my table or i view the table list
8) see 5
9) Do you mean chat to Lobby (all), i don't need that i have lobby chat turned off
But it might make sence to create a team match chat room (smaller group)
10) Only need that information when i activate a tourney list view
11) see 10 or if i am registered or put myself on the partnership desk
12) Lets deal with them when they come up.

Worst thing that could happen is that it takes a few (milli)seconds, if i enter the table/tourney list, but I'm doing nothing else then.

Does your ISP support broadcasts on IP level? You create a "broadcast IP-number" at your ISP's router, that represents e.g. all IP-numbers of kibs at a vugraph match. If you send the data to this "broadcast IP-number" at your ISP's he will distribute the message to all clients in the IP-list defined before. Save bandwidth between you and your isp, but your isp will charge the full outgoing traffic of cause.

Several years ago, I remember noting in my work that no US ISPs had IP multicast turned on. To my knowledge, that is still the case. Even if one ISP did it, you'd need every ISP to do it to help the vugraph issue. The only moderately useful "multicast" services are all overlay based means they are implemented on top of the network and not within it. MBone is just such an example. It would be pretty cool if vugraph video was broadcast on the MBone. I'd go through the hassle of installing the stuff if I could get it. Anyway, I think there are some services that for a fee will provide the multicast overlay infrastructure but since we have clients all around the world anyway we essentially have such an infrastructure for free. I sent Uday a link to a software library that allowed you to implemented your own multicast overlay network. You could use clients to really decrease the server load for really popular points of interest like vugraphs.

[fred]

Uday and I both agree with Hrothgar (and others) that the massive lobby list is not particularly useful. I think that people *should* have the ability to list all of the people who are online and filter that list in various ways, but I think that most people would prefer to see just a small subset of this list most of the time.

However:

1) We already have the View button and this allows people to customize the lobby list as they see fit. Perhaps the default should not be "show everyone", but new users (who have no friends and don't know what stars and yellows are) might find it strange to log in and see a very small list. Presumably those of you who have posted about "only wanting to see friends and stars" already use the View button for this purpose.

2) Even if the client doesn't display the complete lobby list, it still *needs* the information (ie the IDs and profiles of those who are logged in) for various things. For example:

- You receive a chat message and what to know who it is from
- You go to the partnership desk and want to know the profiles of the people whose names are included
- You go to the Main Bridge Club list and want to know who the people are who are playing at various tables

Yes, we could make it so that profile information was sent to the client on a "as needed" basis, but that would not only require a lot of new coding a lot of rewriting of old code, but it would also mean having to do a lot of waiting for profiles.

So when you say:

"I'd guess that you can realize enormous load savings with minimal impact on end users simply by redesigning the main lobby."

I am sorry, my friend, but your guess is wrong

Whatever we choose to do in terms of scaling, what we now call the "lobby' (ie the first screen you see when you log in to BBO) will likely be different in the future.

Fred Gitelman
Bridge Base Inc.
www.bridgebase.com

[fred]

Sorry I have to stop working for the day soon and I don't have time to properly address the good points made by Dr. Todd, hotshot, and others.

For now all I will say is that I still think that all of your concerns and desires will be addressed by the way I see the mini-BBO plan working. Perhaps I have not done a good job of describing the user experience that I envision. I will try again tomorrow.

Fred Gitelman
Bridge Base Inc.
www.bridgebase.com

[Patapon]

I have read most of this thread but i am still not sure to understand very well how would work the 'mini BBO'.

Let's take examples:

Let's say I log in to a mini BBO, the one with the main bridge club.

- Could I see all my friends online even if they are logged in to another mini-BBO and could I chat with them?
- Could I register for a tournament and invite any players online to play with me, even if they are logged into another BBO? And then should I change my log into another mini-BBO to play the tournament?
- Could I know if a vugraph is running on BBO2 when I am logging in to BBO1 and should I change my log to watch the vugraph?

If I just have to log off and log on in to another BBO to watch a vugraph or play a tournament I have just registered for, I don't think it would be a real discomfort since it doesn't take more than two seconds to log off and on again.
But if I can't see, chat or invite my friends through the different BBO then I think it can't be a good idea. Nobody wishes to see BBO divided.

Benedicte

[david_c]

fred, on Mar 25 2005, 07:04 PM, said:

2) Even if the client doesn't display the complete lobby list, it still *needs* the information (ie the IDs and profiles of those who are logged in) for various things. For example:

- You receive a chat message and what to know who it is from
- You go to the partnership desk and want to know the profiles of the people whose names are included
- You go to the Main Bridge Club list and want to know who the people are who are playing at various tables

Yes, we could make it so that profile information was sent to the client on a "as needed" basis, but that would not only require a lot of new coding a lot of rewriting of old code, but it would also mean having to do a lot of waiting for profiles.

I'm convinced that in general the "as needed" approach is preferable. It seems fairly clear that for the three examples Fred gives of why profile information may be needed, "as needed" is the better way of providing the information. This is simply because the amount of infomation involved is small (being a mathematician I would call it "bounded"), so the wait would not be very long (tiny compared to the expense in keeping all users updated).

An "as needed" approach would be useful even when there is an obvious need to be "in synch", as for example when you're looking at a list of tables. The point is that you only need to be "in synch" with one part of BBO at a time. There would surely be a huge difference in the load on the system if each user was only ever in synch with at most one of:
- full online list
- tables in main bridge club
- tables elsewhere
- tournaments
etc.

But there's one thing which people want to be in synch with all the time: that is, which of their friends (and other interesting people) are online. In order to provide this information on an "as needed" basis, the server would need to know the friends of everyone who was currently online. And whenever someone logged in or out, the server would have to search to find out who had this person as a friend. I'd have thought that this would be much more of a load on the server than the current method. So, the fact that we're only interested in a small subset of the online list is of no help at all; we're doomed to be in synch with the entire online list whatever happens ... or have I analysed this wrong?

[TimG]

fred, on Mar 25 2005, 01:43 PM, said:

I personally don't think "constantly in synch" is necessary, but it is certainly desirable in some areas. For example, if you are looking at a list of table in the hope of finding a place to play and if the list doesn't update itself automatically, you will frequently try to sit in an empty seat that has since been filled. Furthermore, having to click a "refresh" button constantly is a big pain. People with slow connections would also suffer every time they went to into the Main Bridge Club (or clicked the "Tables" button) because they would have to wait for the table list to download. The bigger BBO gets the bigger these problems get.

Does all information have to be treated the same? Yes, if I'm looking for a table with an opening, it makes sense to have the table information constantly updated for the tables with openings. If I'm looking for a table at which to kibitz, a non-refreshed list will be sufficient 99% of the time, and I'm sure I can live with the occasional attempted trip to a table that has just closed.

In the lobby, we can use the "view" option to limit which players are listed (something I was not aware of until reading this thread), but as I understand it, even if I set my view to show friends only, the complete list of players is constantly updated in the background. That is, changing the view preferences does not change the bandwidth used.

Once I see a listing of available vugrah shows, I can mouseover the tables and see who is playing. Once I join a vugraph table, I can mouseover the table and see who is kibitzing. Somebody who signs on to find a pickup game has no need for any of this vugraph information. (And, someone who signs on to watch a vugraph has no need to have the main bridge club table info.) Would it be possible to turn on the constant updating for vugraph tables inly when the member has entered the vugraph theatre (or even the explore bridge menu screen)?

If it is possible, the same could be done for other areas: only turn the background updating on for the area where the player is, make it a request for other areas.

Tim

[fred]

david_c, on Mar 26 2005, 01:38 AM, said:

fred, on Mar 25 2005, 07:04 PM, said:

2) Even if the client doesn't display the complete lobby list, it still *needs* the information (ie the IDs and profiles of those who are logged in) for various things. For example:

- You receive a chat message and what to know who it is from
- You go to the partnership desk and want to know the profiles of the people whose names are included
- You go to the Main Bridge Club list and want to know who the people are who are playing at various tables

Yes, we could make it so that profile information was sent to the client on a "as needed" basis, but that would not only require a lot of new coding a lot of rewriting of old code, but it would also mean having to do a lot of waiting for profiles.

I'm convinced that in general the "as needed" approach is preferable. It seems fairly clear that for the three examples Fred gives of why profile information may be needed, "as needed" is the better way of providing the information. This is simply because the amount of infomation involved is small (being a mathematician I would call it "bounded"), so the wait would not be very long (tiny compared to the expense in keeping all users updated).

I think you are wrong.

First of all, the amount of data that you have to wait for is not the only relevant factor. It takes time for your request for that data to get to our server, for our server to process that request, and for the data to be returned to your PC. Also, if the basic system design is changed so that the server starts to receive a *lot* of these kinds of requests, there is danger that it will become bogged down trying to deal with them.

Second, you use words like "preferable" and "better" inappropriately in my opinion. "Better" from what point of view?

Clearly from the user's point of view better means:

- Client never has to wait for anything
- Client interface is designed so that it is always easy for user to see and do whatever he wants

Whereas from the server's point of view, "better" means:

- Server does the minimal amount of work per user so that it can handle as many simultaneous users as it will ever need to

What is "best" for the user directly contradicts what is "best" for the server.

Our mission is to change the basic client/server and/or client interface design so that this contradiction can be managed for large numbers of users while at the same time minimizing the negative impact that these design changes will have on the user experience.

Fred Gitelman
Bridge Base Inc.
www.bridgebase.com

[fred]

Answers to questions from Patapon:

- Could I see all my friends online even if they are logged in to another mini-BBO and could I chat with them?

Yes.

- Could I register for a tournament and invite any players online to play with me, even if they are logged into another BBO? And then should I change my log into another mini-BBO to play the tournament?

Yes and yes (though you wouldn't have to do anything when the tournament started - the software would automatically connect you to the appropriate mini-BBO)

- Could I know if a vugraph is running on BBO2 when I am logging in to BBO1 and should I change my log to watch the vugraph?

Yes. The default would be for all vugraph tables be "shared" among all mini-BBO, but we might want to give vugraph operators the ability to create "private" vugraph shows that would be available on only 1 mini-BBO.

Same goes for things like tournaments and private/public clubs. The default would be that these things would be shared by all mini-BBOs, but we would likely build in the ability to restrict access to such things to people logged into a particular mini-BBO (or particular mini-BBOs).

The main differences between what we have now and what we would have under the mini-BBO plan (at least as I see it) would be this:

1) Each mini-BBO would have its own Main Bridge Club and each of these Main Bridge Clubs would have their own unique lists of tables.

2) The lobby list of a given mini-BBO would contain only people logged in to that mini-BBO.

3) We would create a new window that contained things like a list of all available mini-BBOs and a customizable list of people logged in to those BBO (perhaps the default would be friends only, but you could also use something similar to the current View button to change the contents of this list).

This window would be available at all times. It could be used for things like switching to a different mini-BBO, chatting with people on other mini-BBOs, etc.

So when you first log in you would see this window. When you then use this window to log in to a given mini-BBO, you would see something similar to what you see now when you log into the one and only BBO. After you logged in to a given mini-BBO, this new window would remain available.

Fred Gitelman
Bridge Base Inc.
www.bridgebase.com

[TimG]

fred, on Mar 26 2005, 12:45 PM, said:

- Client never has to wait for anything

When I sign on to BBO, I get a couple of messages:

"Logging In. Please Wait."

"Loading Player List. Please Wait."

So, you'll never achieve perfection in this area. There also must be some delay with the communication of data under the current background updating environment. It's probably cut up into very short delays so that we hardly notice, if we notice at all. I wonder: would there be fewer apparent delays in bids or cards played if background updating were not constant?

Not that this is meant as a criticism. I expect to wait for some things. I expect to wait while a connection is established and some system state is communicated to my computer. I think you would also find that most people would accept (even expect) to have some minimal wait when some things (like a lobby listing) are requested.

You should be aware that while I may seem to have a strong opinion here, any change to mini-BBOs is unlikely to alter my usage habits. So, perhaps, my opinion is not one you need to hear. (And, just maybe, I'll manage to keep quiet on the matter from here on out! )

Tim

[hotShot]

What about this:

I guess each user has an ID ( think 4Byte integer should do) than sending a message to all user takes
active user * 4 Bytes as an initial Message. Adding 2 extra Bytes for the table number (could make problems if BBO reaches 32000 active tables) (table 0 is lobby) and one Byte bitcoded N/S/E/W /Kib /Yellow/tourney/logoff / changed profile etc. will lead to 7 Bytes per active user at login as an absolute minimum.

When installing BBO (not at update) the usernames and id are mirrored in a local database. Name and id cannot be changed so these data never expire. It could also contain the friend/enemy status. The profile of friends should be mirrored locally too.

If i want to see someone's profile the request is send to a different server e.g.
profiles.bridgebase.com this server is just handling the profile. This could be done with a direct connection to a database server. Parsing the SQL request output is done by the client. Keeping the answers fast could be done e.g. with a MYSQL cluster (but i guess BBO must grow a lot before that is necessary). People could choose how much space they would be willing to reserve for cached profiles, if there is space left those profiles can be mirrored locally too, if a login message indicates a profile change it is marked invalid in the local database, and called again from the server.
I guess profiles of 100000 user take about 50MB,Not transmitting all the profiles all the time would help to save bandwidth and allow faster logons. (Guess you do a lot of this already.)

Login and logout, seating information change of status will lead to 7 byte messages. Since these messages are send to all users this can be done by some sort of client based distribution. If you send this to 2 player at the table asking each to redistribute the message to the 2 others, the others might get the message twice, but the will sure get it. A similar idea can be done with table chat. I know you don't like to rely on the clients, but sending update information only to half of users using them to proxy the data to 2 others will reduce the bandwidth you need. If each message has a message id, a client can see that he missed something and can contact a server lostmessage.bridgebase.com asking for the message with the missing id. Or take a look at all those bittorrent distribution systems. They work! Since you can really save bandwidth this way you should think about it.

[uday]

Quote

maybe, I'll manage to keep quiet on the matter from here on out

No, don't keep quiet just because one of us disagrees with you!

[fred]

We already do similar things to almost everything hotshot describes in his post.

Implementing these sorts of things has bought as a lot of time and greatly increased BBO's maximum capacity over the years, but they are still what I would call "bandaid solutions". There are probably still a few clever undiscovered bandaids out there, but eventually we will run into a brick wall as far as the existing architecture is concerned.

Fred Gitelman
Bridge Base Inc.
www.bridgebase.com

[Rebound]

fred, on Mar 26 2005, 02:30 PM, said:

Answers to questions from Patapon:
<snip>

This reply is sufficient to pretty much address every concern I may have had regarding the changes. The way you describe it, Fred, it sounds perfectly fine to me :-)

[Rain]

My dream BBO, hopefully it'll be incorporated in the next 3 years. Similarities to WOW and other MMP games are intended.

You login to BBO and are asked to select an avatar. If fred decides to provide a premium BBO service, an additional feature would be more avatars for premiums, and ability to customise avatar. (hairstyle, facial features, clothes or no clothes)

Next you choose a realm to play in. Each of these have specialisations, and are the mini-BBOs mentioned. Instead of naming them "China BBO" or "Italian BBO" they get cool names like "Forbidden City (with chinese translation) and "Leaning Tower (with Italian translation)". Each realm has its own themed colour scheme and background pictures.

When you enter, you appear to be walking in the 3D realm. If people are standing, they are in the lobby/idle. If they are playing, you'll see them sitting and playing. Seats are also different depending on which realm. Eg will be if you are in Japanese land, you see people kneeling at a Japanese low table and playing cards, heh.

Your avatar can walk around the landscape scattered with tables, or they can just click on menu buttons on top to locate friends and join their table.

Once at table, you get to kibitz 1 person at a time. If you want to kibitz 2, you need to stand behind 2 people. If you want to kibitz all, you'll be magically suspended on top of table.

When playing, you will sit at a table, and hold cards in your hands. The camera is behind you so all cards are clearly shown.

----------------------
Bonus/special points:

You get certain interaction chat like actions that your avatar can do. (The bbo version prior to this isn't as advanced, and will only have emoticons) Eg, and this is blatant lifting, you choose "shake hands" and your character shakes hand gravely with other users. Or dance. Or laugh, which will cause your avatar to roll on floor and laugh loudly)

The more boards you play, the more activities you do in BBO, the more experience points you get. The more experience points you get, the more benefits and privilages you get. If you don't play for a long long time, you can also lose XP. The special feature we have will be: If anyone abuses you, you can draw your weapon and hack at that person's avatar. Around the landscape there will also be interactive features for you to interact with to distract you more from bridge. Something like a rhino or hippo or giraffe that you can ride if you are in the african part of the landscape.

If you want to buy BBO$, you go to the bank and your character will get a theft-proof bag with coins in it to jiggle.

If you play in a tourney (if pay tourney, you get to hand a sweet looking TD your silver coin) and play too slow, the TD can choose to make angry faces at you. If that fails, they can also adjust your score.

There are special "Quests" you can do to gain more XP. These will mostly be tutorials around this new BBO or a Guide on how to be a good TD with a quiz at the end.

To travel from 1 realm to another, you can actually walk to the "bridgeport" and take a "travelling scorecard" to the next realm. (There will be a cool, very short clip with "wheeeeez!" showing you sitting on travelling scorecard and going to the next realm's bridgeport". You don't get frequent flier miles, but you do get to sit in the clubhouse if you are of a high enough level.


How about it Fred? BBO 2008? Or 2048 =(

Rain