[hrothgar]

Sigi_BC84, on May 22 2006, 08:07 PM, said:

If the phone is turned off, what is emitting the signal to be located (by whatever means necessary)?

There is no way to locate a cell phone if it's turned off (for all currently applicable definitions for "turned off").

Claiming the contrary is spreading urban legends and conspiracy theories.

For what its worth, I was product manager for the TCP/IP stack that was incorporated into most of the Nokia / Ericsson cellphones.

The main thing that I learned about these phones is not to apply concepts like "common sense" to cell phone architecture. Case in point: A few generations back, many popular cell phone designs like the Motorola Star Tac featured prominent antennas that people could extend. One might think that the fact that the designers built a visible external antenna (with a telescoping extension even) had something dto do with reception. In actuality, the designers want people to think that thye could improve recption. The external antenna was completely transparent. The "real" antenna was a U-shaped coil built into the casing.

Another interesting little data point that I learned about many small embedded devices is that they are "always" on. If you turn the device off, you shut down the GUI and a many of the more power hungry applications. However, a lot of the basic functions (like Bluetooth) are still up and running.

[Sigi_BC84]

Walddk, on May 22 2006, 07:17 PM, said:

I am sure you know a lot about these technical aspects (I am absolutely clueless), but excuse me for asking. How is it related to the topic: "How can Vugraph be improved"? - "realistic suggestions only, please".

How come you are asking me and no one of the other posters who actually started writing about locating cell phones?

But of course you are right, this is horribly off-topic and should be moved to the water-cooler.

--Sigi

[foo]

Jan, Roland, Uday, Fred:

Just what additional non-personel related infra-structure would be needed for BBO to have every thing they needed, except possibly people, to handle the projected load this August if we wanted to pursue the "holy grail" of recording as many of these sessions as possible on vugraph?

Are we short on network capability? Servers? Does the BBO SW have some limitation in it? etc


Also, I'm going to risk being marked a heretic here and note that if given the choice between a vugraph w/ little or no commentary and no vugraph at all, I'd pick having vugraph available 100% of the time!

Even w/o commentary, just the fact that there is a permanent record of such caliber bidding and play is invaluable.

[JanM]

foo, on May 22 2006, 06:35 PM, said:

Also, I'm going to risk being marked a heretic here and note that if given the choice between a vugraph w/ little or no commentary and no vugraph at all, I'd pick having vugraph available 100% of the time!

I'd be willing to bet that you're actually in the majority on that - we'd all rather have Vugraph without commentary than no Vugraph, I think.

[fred]

foo, on May 22 2006, 11:35 PM, said:

Jan, Roland, Uday, Fred:

Just what additional non-personel related infra-structure would be needed for BBO to have every thing they needed, except possibly people, to handle the projected load this August if we wanted to pursue the "holy grail" of recording as many of these sessions as possible on vugraph?

Are we short on network capability? Servers? Does the BBO SW have some limitation in it? etc


Also, I'm going to risk being marked a heretic here and note that if given the choice between a vugraph w/ little or no commentary and no vugraph at all, I'd pick having vugraph available 100% of the time!

Even w/o commentary, just the fact that there is a permanent record of such caliber bidding and play is invaluable.

There is an arbitrary constant of 8 built into both the client and server that limits the number of vugraph tables.

There is nothing sacred about 8 - we could have made it 800 (or anything else for that matter). At the time this constant was established (4+ years ago) 8 seemed like more than enough.

It would be trivial for us to create new versions of the BBO server and client that could support more than 8 vugraph tables. However, anyone using an older version of the BBO client would experience problems whenever a 9th or subsequent vugraph table was formed.

Uday and I are working on a solution. In a worst case scenario we will release a client that supports more than 8 tables, but leave the server limit at 8 for several months. By that time hopefully almost everyone will have a newer client and we can then release a new server that:

1) Supports more than 8 vugraph tables
2) Prevents old clients from logging in

Obviously it would have been better if we had thought about this earlier...

Fred Gitelman
Bridge Base Inc.
www.bridgebase.com

[foo]

I suggest that the client SW have no hardcoded limits in it and that the server side limits be in a config file somewhere on the server (eg, not hardcoded either) so that it can be easily changed depending on network bandwidth, server horsepower etc.

However, that doesn't answer the fundamental question as to whether the existing BBO infrastructure has the horspower, bandwidth, etc to handle the projected load?

[fred]

foo, on May 23 2006, 12:19 AM, said:

I suggest that the client SW have no hardcoded limits in it and that the server side limits be in a config file somewhere on the server (eg, not hardcoded either) so that it can be easily changed depending on network bandwidth, server horsepower etc.

However, that doesn't answer the fundamental question as to whether the existing BBO infrastructure has the horspower, bandwidth, etc to handle the projected load?

The number of vugraph tables does not have a serious impact on things like overall system performance, bandwidth, etc.

The only factor that really matters as far as these things are concerned is the total number of people who are logged in. What they are doing when they are logged in (playing, watching vugraph, chatting, nothing, etc) is only a minor factor.

As for your design suggestion, it might have been smart for me to do something along the lines of what you describe in the first place, but it did not seem to be necessary or desirable at the time. It was hard to foresee that we were going to need to support more than 10K simultaneous logins, more than 8 simultaneous vugraph tables, more than 100 private clubs, etc.

And it is easier, faster, and safer (for me at least) to write code that contains limits on such things.

Fred Gitelman
Bridge Base Inc.
www.bridgebase.com

[mrdct]

Fred,

Can you clarify whether the invisible vugraph tables are counted within the limit?

Dave.

[uday]

The limit is imposed on "Vugraph Tables". Visible or invisible , they count.

[barmar]

fred, on May 22 2006, 08:42 PM, said:

And it is easier, faster, and safer (for me at least) to write code that contains limits on such things.

Is this stuff written in ancient Fortran or BASIC? In most decent programming languages it's not that hard to resize arrays on the fly (realloc() in C).

You probably could have gotten away with the same answer you gave for why the "Show played cards" option turns itself off, instead of admitting that you're just taking the easy way out.

[cherdano]

barmar, on May 23 2006, 04:32 PM, said:

fred, on May 22 2006, 08:42 PM, said:

And it is easier, faster, and safer (for me at least) to write code that contains limits on such things.

Is this stuff written in ancient Fortran or BASIC? In most decent programming languages it's not that hard to resize arrays on the fly (realloc() in C).

Um. If you feel the need to give Fred a C tutorial, which he certainly doesn't need from this forum, you should better damn make sure you are right. You can't reallocate static arrays, and even if you can realloc() this data, it is very dangerous if you have other pointers to (parts of) your structure, and a VERY common source of bugs.

Arend

[fred]

barmar, on May 23 2006, 02:32 PM, said:

fred, on May 22 2006, 08:42 PM, said:

And it is easier, faster, and safer (for me at least) to write code that contains limits on such things.

Is this stuff written in ancient Fortran or BASIC? In most decent programming languages it's not that hard to resize arrays on the fly (realloc() in C).

You probably could have gotten away with the same answer you gave for why the "Show played cards" option turns itself off, instead of admitting that you're just taking the easy way out.

The client program is written in C.

Realloc only works on a block of memory was created with malloc.

The arrays in question are not created using malloc (or any other form of dynamic memory allocation) - they are not arrays of pointers - they are just arrays.

In any case, making the array bigger is not the problem - all that would be involved would be changing a line of code that currently says:

#define MAXVUGRAPHTABLES 8

The problem (as I tried to explain) is backward compatibility with old clients.

I would just as soon avoid an intense discussion of programming techniques and methodology here. While I have no doubt that there are forums readers who were paying attention in college (as opposed to playing bridge like I was), I doubt that anyone out there has written a program that is anywhere close to as complicated as the BBO client. If they did then probably they did a much better job of the early design than I did and are not familiar with dealing with the type of problems we face now.

The real solution to these problems is to get it right the first time. If you don't then problems with no good solution (like this one) are bound to arise eventually.

Fred Gitelman
Bridge Base Inc.
www.bridgebase.com

[jdonn]

fred, on May 23 2006, 10:21 AM, said:

While I have no doubt that there are forums readers who were paying attention in college (as opposed to playing bridge like I was),...

Guilty eyes shifting nervously...
No comment.

[Sigi_BC84]

fred, on May 23 2006, 05:21 PM, said:

I doubt that anyone out there has written a program that is anywhere close to as complicated as the BBO client.

Um, while I'm not one of these people I strongly assume the opposite. How convoluted must the BBO client's source have become over time so that you are making such a statement in all seriousness??

--Sigi

[fred]

Sigi_BC84, on May 24 2006, 09:46 PM, said:

fred, on May 23 2006, 05:21 PM, said:

I doubt that anyone out there has written a program that is anywhere close to as complicated as the BBO client.

Um, while I'm not one of these people I strongly assume the opposite. How convoluted must the BBO client's source have become over time so that you are making such a statement in all seriousness??

--Sigi

Well I could easily be wrong, but I suspect you have not fully consider the complexity of the program. Consider for example the following complicated things that are all part of the BBO client:

- code for rendering "rich text" (maybe the wrong term - I mean, for example the code that appears in chat and, more generally, in any .lin file) including text from languages with 2-byte character sets (like Japanese for example)

- code that provides the smarts for Bridge Master

- code for interfacing with things like GIB, FD, and (especially) Internet Explorer. Try doing this in C if you don't believe me that it is complicated (and if you are successful please send me some code samples!).

- code for doing some tricky graphics related things (like card animation). Yes, I could use a 3rd party library for this, but I don't.

- code for parsing and dealing with over 500 types of server->client messages. Most of these are not too tough to deal with, but collectively it still represents a lot of code. There are over 200 types client->server messages as well.

- network code. I did not write this part of the client (good thing!). If you think it is easy to get this right, you are either a genius or you are very naive.

- there is a whole class of problems that Uday and I call "race conditions" that are hard to avoid and hard to deal with in any client-server application in which more than one person can simultaneously take actions that effect one another. Server-generated events that are the result of timers (as opposed to actions of users) such as tournaments starting further complicate things.

Or you could just count the number of lines of source code. I am not sure of the exact number, but it is certainly well over 500,000. That seems like a lot to me.

I do admit that there are various ways that I could have made life easier for myself, but that is not the point. The point is that, in my opinion (and I am pretty sure I am right), that there are very few programmers out there who have ever written a program anywhere close to as complicated as the BBO client (especially on their own as opposed to as part of a team of programmers).

Fred Gitelman
Bridge Base Inc.
www.bridgebase.com

[Sigi_BC84]

Quote

Well I could easily be wrong, but I suspect you have not fully consider the complexity of the program.

Believe me, I did consider the complexity of the program. I assume that we are talking about the client, thereby not taking into account many issues related to full client/server operation, efficiency and scalability of the protocol and the server implementation. These are tricky issues especially when not planning ahead and having no prior experience (now nobody blames you for not planning ahead to cater for 8000+ users, mind you).

Quote

- code for rendering "rich text"

100% something you don't want to implement yourself.

Quote

- code that provides the smarts for Bridge Master

Different product.

Quote

- code for interfacing with things like GIB, FD, and (especially) Internet Explorer. Try doing this in C if you don't believe me that it is complicated (and if you are successful please send me some code samples!).

If the third parties involved are not able to provide you with a reasonable C API I readily admit that it is a pain in the butt to interface with such applications through other means (if you have to use C). I don't know much about using the Internet Explorer component, it's supposed to be easy to use, but I wouldn't be surprised if the opposite was true.

I'm not sure what I myself would do, probably use a lightweight HTML browser component that fits the special needs for my application (a huge amount of IE rendering capabilities are unused by BBO anyway).

Quote

- code for doing some tricky graphics related things (like card animation). Yes, I could use a 3rd party library for this, but I don't.

Well, I don't know how much low-level work you do in fact, but if it boils down to drawing the pixels mostly yourself I'd say, yes, that is a lot of work (not to say a lot of time rather spent elsewhere *duck*).

Quote

- code for parsing and dealing with over 500 types of server->client messages. Most of these are not too tough to deal with, but collectively it still represents a lot of code. There are over 200 types client->server messages as well.

- network code. I did not write this part of the client (good thing!). If you think it is easy to get this right, you are either a genius or you are very naive.

It's definitely not easy to get point one right, but point two should be pretty straightforward. Then again, maybe it's a pain under Windows or used to be that way when you started working on BBO (under Windows 95 proper or Win NT presumably). I don't know for I have avoided Win32 successfully so far, but opening a TCP stream on both ends and sending/receiving your protocol over it shouldn't be the main challenge (or is it?).

Quote

- there is a whole class of problems that Uday and I call "race conditions" that are hard to avoid and hard to deal with in any client-server application in which more than one person can simultaneously take actions that effect one another. Server-generated events that are the result of timers (as opposed to actions of users) such as tournaments starting further complicate things.

Yeah, very tricky. Mainly the point of designing a good protocol (which is obviously not easy). If it happens that you have to plug a lot of holes when the system grows this is obviously a source for quite a lot of code complexity...

Quote

Or you could just count the number of lines of source code. I am not sure of the exact number, but it is certainly well over 500,000. That seems like a lot to me.

It is, but we are talking about a client for a card game including several general purpose libraries you apparently happened to have written in the process. I did not take that into account with my first reply.

Let me finish by saying that I'm not suggesting that the BBO client is some trivial piece of undergraduate homework. It's not the Linux kernel either, however...

--Sigi

[fred]

Sigi,

My post was about "here is why the BBO client is a very complicated program".

Your post was about:

"you are right that some parts of it really are complicated" (true)

and

"I don't know enough about Windows or about various other parts of the BBO client to comment, but I don't believe you when you say these parts are complicated" (remarkable)

and

"it should not have to be so complicated" (true but irrelavent)

and

"I define the BBO client program as being something other than what the BBO client program is" (non-sequitor)

The reason I made the statement that started this discussion in the first place (ie that I doubt there are any forums regulars who have written a program as complex as the BBO client) was to try to avoid receiving programming lessons from people who may have the knowledge, but lack the experience to be helpful.

Bridge players and programmers have at least one thing in common. Many talk a good game, but when push comes to shove, very few are able to execute. At least that is what my experience as a programmer (30 years) and a bridge player (20 years) tell me.

If there are any forums regulars reading this (besides Uday) who have written very complicated programs, please identify yourselves. I will be more than happy to admit that I am wrong. Otherwise, I doubt I will anything more to say on this subject.

Fred Gitelman
Bridge Base Inc.
www.bridgebase.com

[Sigi_BC84]

fred, on May 25 2006, 02:30 AM, said:

"I don't know enough about Windows or about various other parts of the BBO client to comment, but I don't believe you when you say these parts are complicated" (remarkable)

The only one of my remarks to which this appropriately refers to is the one dealing with the complexity of an Internet connection (TCP). I maintain my position that it is easy to setup and maintain such a connection programmatically and using it for communication purposes with the server (specifically this is all I'm saying, not that there aren't indefinitely many ways to actually have it complicated).

Quote

"it should not have to be so complicated" (true but irrelavent)

You've listed a fairly extensive list of "sore spots" regarding complexity and I couldn't hold myself back from commenting on it. Granted that it is irrelevant to refuting your original claim.

Quote

"I define the BBO client program as being something other than what the BBO client program is" (non-sequitor)

I was not aware that the Bridge Master logic is actually included in the BBO client program. I would also go so far as to say that by implication the term "client program" should not refer to program logic completely unrelated to BBO.

Quote

The reason I made the statement that started this discussion in the first place (ie that I doubt there are any forums regulars who have written a program as complex as the BBO client) was to try to avoid receiving programming lessons from people who may have the knowledge, but lack the experience to be helpful.

Along these lines most movie critics and literature reviewers should shut their mouths for good. Not having actually written something comparable in complexity to BBO does not necessarily preclude somebody from commenting on its technical merits.

Someone might for example know about a certain toolkit or general approach that would apply nicely to BBO and you should be ready to take such advice serious (I'm sure you do BTW) even though said persons might not have written an internet game before.

--Sigi

[jdonn]

Sigi, Fred has made it so obvious he doesn't want to be having this discussion. Who even cares if you are right or not. Just let it go.

[Elianna]

fred, on May 24 2006, 04:30 PM, said:

If there are any forums regulars reading this (besides Uday) who have written very complicated programs, please identify yourselves.

Does "Hello World" count?