Results 1 to 4 of 4
Enjoy an ad free experience by logging in. Not a member yet? Register.
Socket Server breaks after 1000 client requests
I wrote C++ Socket class. This class wraps methods both for client and server,
so you can create server or client depending what methods you call.
Anyway, all in all, problem is:
I have 3 small programs. One is server that listens in loop on port 30000.
Second is client program that sends one message to the server.
The third one on is small program (called spawn) that forks and executes client program in limited for loop. So , idea is to simulate a lot of connections to the server and see how many he can handle and how.
So, at first I start server, execute spawn, and server gets client messages. First I try 10 clients, then 100, then 1000 and it worked Then I tried 10000 clients, and then it breaks just above 1000 clients, plus minus 100 !! So then I tried to put in server code 5 threads and mutex, but the result is same around 1000 clients and breaks. Then I put semaphore, but then i realized that in this scenario semaphores are of no use, because you can not sync with random client events.
I also tried to change value in listen() method, but then I read somewhere that maximum is 5 connections, which is default.
Does this problem requires some change in kernel code, or tcp/ip stack, or the solution is simple, like reset server when it has first break. I tried this last solution, but nothing happens.
So , does anyone have any idea?
Please help, I am working on this for days
- Join Date
- Sep 2009
2 high 5 equals 32 times 32 equals 1024 equals 2 power10. On a 32-bit machine it rings a bell somehow.
Then, cut your limited loop, use an IF loop with an EOF - end of file - trigger to stop/exit the program. With counters you concede control to the machine. Without tight control on the counter when exiting the loop you create madness.
the thing that you wrote seems to make sense. Can you be little bit more specific ??
- Join Date
- Sep 2009
Abject apologies for coming back this late. We had to do some nursing in the family.
It works something like this. The figure 1024 is just above 1000 - which rang a bell. It's a no-brain thing since a 16-bit register can only count to 2 to the power 16 minus 1, (it starts counting at num=0 , num+1 etc, Option Base 0 in MS Basic - very old) which looks like this 1111 1111 1111 1111. Add another 1 and you get 0000 0000 0000 0000, so you start counting all over - at the bottom.
That is why we now have 32 and even 64-bit computers. 2^64 gives you in the region of 2 Tera Giga bytes (1.844674 ^19) of memory which should be enough for now. The A and D registers can actually count that far. Now you also have to have things like double double words to ferry the counts. In just double word computing you may only address even numbered registers or else the stuff falls of or gets garbled. Hence the wording "64-bit technology" or similar. Horses for courses. The wording long() or similar in C tells the program where to hit the register's boundary or rather which register. Double word or single word.
Today's computers are very fast and fancy yet they still are just the quick idiots they were in yesteryear, they still do the work in exactly the same way at heart. Problem now is that you do not see what they do at the bottom hardware level.
The issue is; the size of the register causes a boundary. The 1 you added above, fell off the register on the left hand side as a carry. The register simply cannot handle it.
This is the kind of thing you have to look for. printf in C is not C. It is a "sub-routine" or "function" made up of C elements. The computer is a donkey and crunches numbers down the circuits regardless. You have to find out the specific pattern of input so that you get the desired result.
I wrote a bus fare table with routes and stops in Microsoft Basic once and could not add bus stops to an existing table without it going all over the place. This happened using the recommended MS Basic program statements. It said you could simply open a file and start adding records. Not on your life!
I wrote a file with a header identifying it and keeping the current count of stops to be updated as I edited the file. At the moment you are on remote control and should research what your counters are doing. They don't call it number crunching for nothing!