unknowen

Hi, can anyone can give me hint where to look for some samples or documentation.
To write complex server system.

I need to colect info from many clients and alow to interact them.
Not sure if fork is realy good idea, because as I understand I don't get shared memmory ;(. Thread per client also is bad in linux. I've read couple of books but noone realy is for linux ;(.

Kylixen

What does this have to do with 2.6?

__________________
ALLOW IMAGES IN SIGNATURES NOW

Pizentios

please post more info. Are you writing your own kernel or somthing, or just a program that gets input from a few users and does somthing with it??

what are you wanting help with is what i am really asking.

__________________
Profanity is the one language that all programmers understand.

Check out my Blog <---updated Nov 30 2007!

Kylixen

It appears he's wanting to write a daemon using sockets and threading. He doesn't seem to understand that it isn't going to be kernel specific...

__________________
ALLOW IMAGES IN SIGNATURES NOW

Pizentios

yeah, no need to worry about what kerrnel you are using dude. We still need more info...

__________________
Profanity is the one language that all programmers understand.

Check out my Blog <---updated Nov 30 2007!

unknowen

Sorry for not answering directly, different time zone.

Will try to explain what I want to do and how.

A little bit of background, I have about 5 years of C/C++ experience all of them used VC++, some time ago at home started to play with Linux, so have to get into new things. And sometimes answer right at your nose, but you don't see it because of windows thinking.

First of all let’s start with kernel, 2. 4 has slow scheduler, but I need fast threading program, so I tested some code pieces with 2.6.7 and performance with POSIX threads are better, of course I understand that I don't need to care about kernel, just want to use fastest one for my MEGA server

Second. Basically I have server to many clients, but clients have to interact with some date. So fork will not work (ok will fork but then I have to manage shared memory - don't want to). I wrote server that works one thread per client using blocking sockets, but after reading some info about Linux this is definitely not the best idea if client number is large.
Switched to one thread listens to all clients that are connected to non blocking socket. Logics works fine for that, except thread who is listening for incoming data, that thread takes al CPU .

At this point I stopped and posted not correctly described question, again sorry.

After reading I found that Linux has function clone (), that works the same way as fork () except this function is working in the same memory space, BUT not portable.

And the answer is function select (), (of course there are others like pool etc), so right now I will write something like this.

1) Thread accepting connections
2) Waiting in select () function on data arrive reads data and posts in worker queue
3) On data arrived worker thread wakes up do some thing and gets some sleep .

HUH long, but will write more.

I'm thinking about other stuff. I have calculated that client will send maximum 2 messages per second; I hope 1 thread should be enough to read them.

Second algorithm I thinking of is - Thread accepting connections and on each new ten clients creating thread that goes to select () function on data arrive process all data, and wait for next data.

Here I see some more jobs, because I have to control disconnecting client count, so I don't get situation that in some cases thread is working for one client only.

Any ideas or comments are welcome.
If someone wants I can tray to explain more detailed what I'm going to write and put some code pieces as well.

P.S. I'm not a native speaking English, so sorry for my mistakes

kurifu

Network socket polling is ugly, and should always be avoided, and thus you are going to have to deal with treading at one point or another if you want more then 50 clients to connect to your server at a time.

Shared memory is possible, but like always not easy to work with on Linux, it was not designed for that purpose, but I have seen it done.

You do not, however, want a thread per client, that can get really messy... use one thread for every, oh say 32 clients (experiement until you find an efficient value), you would essentially create blocking or non-blocking sockets and select from a list of them at once. As soon as one or more of them become "active" on a thread, then you continue to process information on those sockets.. this process blocks though to prevent polling.

Polling sockets is worse then threading them...

__________________
Clifford Matthew Roche &lt;geek@cliffordroche.com&gt;
Web Hosting: http://www.crd-hosting.com
Consulting: http://www.crdev-consulting.com

unknowen

So you say, my described second algorithm will be better...

Pooling you ment exact implementation or all these select/pool/etc technologys together?

kurifu

I had a conversation on this very topic with a few follow programmers (also working in the field) not 1 month ago.

I had a while ago written a server/client system which used pluggable factories and drivern completely of piped connection, one thread per client two sockets per thread (one incomming one outgoing) for each client... the outgoing stream was non-blocking and the incoming stream was blocking on each thread, allowing for a great deal of efficiency, so long as I kept the max users to a reasonable number and enough memory for my stacks and heaps.

This is really a bad design though where scalability is a factor, large server loads and large thread counts are just nasty, you would suck up resources quicker then you would be able to manage, you wouls pretty much choke out your server unless you had insane memory to work with. (memory is expensive, so usually you deisgn without this philosophy in mind).

Polling sockets on the other hand are less realtime, since you have to wait to poll before you will know there is data adding slight delays before actually processing information, this is of course associated with non-blocking sockets; however you could reduce the delay by constantly processing, which is alright if you do not care about the wasted CPU cycles that go into the pooling loop (and that is about 99% of the processor).

The optimal way to manage this is a balance between the two... use sets of sockets, anywhere from 32 - 128 per thread (all operating system have a different max), use FD_SETs to go into waiting states on your sockets and wait for incoming data on one or more sockets in each of these threads. When a socket becomes active, you lock all the sockets on that thread (or if you are really good matain a mutex/cirtica_section for each socket so that you do not read and write on a socket on the same time by accident). Process the incoming data on thta socket, this reduces the number of threads you use, while allowing you to block on sockets in such a way that will not wait only on one socket (and ignore the rest).

You need to make sure you do not read and write to a socket at the same time though, not a problem if your server is 100% event driven (usually not the case) since you will have one seperate thread (another child thread--since the main thread should still be listening for incomming data) to write to any socket that requires writing. Matain the outgoing data through a send-queue, just pop data from the front and send, be sure to lock the socket before sending, and unlock as soon as you are done.

Every time a socket blocks, you will block a few other sockets. Remember that the more threads you use, the more memory you will need, however the more sockets on a single thread, the more data gets blocked when one of those sockets need to write (if it becomes active, it will take the entire list while the thread waits to read). You will need to find your own balance.

On the other hand, using a sending queue on the packet level will always unlock the socket after one send and allow a read which will lock and then unlock after each packet is put into a read queue, so the waits on socket locks are not actually very long, only noteable after many sockets become active with data to read and send.

__________________
Clifford Matthew Roche &lt;geek@cliffordroche.com&gt;
Web Hosting: http://www.crd-hosting.com
Consulting: http://www.crdev-consulting.com

unknowen

thnax kurifu, the select scenario sounds realy resionable for me, now will code and test for some couple of days, will post how it goes