HTTP stream server: threads?

I already wrote here about the http chat server I want to create: http://stackoverflow.com/questions/2352220/alternative-http-port This http server should stream text to every user in the same chat room on the website. The browser will stay connected and wait for further html code. (yes that works, the browser won't reject the connection).

I got a new question: Because this chat server doesn't need to receive information from the client, it's not necessary to listen to the client after the server sent its first response. New chat messages will be send to the server on a new connection. So I can open 2 threads, one waiting for new clients (or new messages) and one for the html streaming. Is this a good idea or should I use one thread per client? I don't think it's good to have one thread/client when there are many chat users online, since the server should handle multiple different chats with their own rooms.

3 posibilities: 1. One thread for all clients, send text to each client successive - there shouldn't be much lag since it's only text this will be like: user1.send("text");user2.send("text"),... 2. One thread per chat or chatroom 3. One thread per chat user - ... many...

Thank you, I haven't done much with sockets yet ;).

Right now, you seem to be thinking in terms of a given thread always carrying out a given (type of) task. While that basic design can make sense, to produce a scalable server like this, it generally doesn't work very well.

Often a slightly more abstract viewpoint works out better: you have tasks that need to get done, and threads that do those tasks -- but a thread doesn't really "care" about what task it executes.

With this viewpoint, you simply need to create some sort of data structure that describes each task that needs to be done. When you have a task you want done, you fill in a data structure to describe the task, and hand it off to get done. Somewhere, there are some threads that do the tasks.

In this case, the exact number of threads becomes mostly irrelevant -- it's something you can (and do) adjust to fit the number of CPU cores available, the type of tasks, and so on, not something that affects the basic design of the program.

Yeah, but the question is if it's necessary to have more than (like) 2 threads. Since this program should only stream some content, i don't think i need a difficult architecture. the main question is: if i only use 2 threads and have, like 50, connections. will there be a problem to send a text message to every client simultaneously?

D.Unknown 2010-03-01 17:20:27

You can manage with 2 threads, but it is not efficient. You can't send text messages really simultaneously. But if you have not too much clients it will be so fast that users will think that it is simultaneous. I would say that it is necessary to have >2 ths.

Andrey 2010-03-01 17:24:10

Is there a limit of threads? When I open a thread per chat, there shouldn't be more than 30 users online, but I want to give my users the ability to create an own chat. so if there is a chat with only 1 user, it'll have its own thread too. (no need for a thread if no one is in a chatroom). the other posibility is a thread pool, but i don't know how to divide the users. - maybe "20 users per thread, create new if full"?

D.Unknown 2010-03-01 17:46:54

there is a limit on threads, but if you use thread pool it is much more efficient utilization of system resources, because threads will spend less time being idle. sharing thread between clients will end in mess, it is bad idea. http protocol is request-response type, so users do not hold thread all the time, so thread pool works best.

Andrey 2010-03-01 18:00:12

Yeah, okay. But this chat idea is not really "request-response" because a response will only end when the user exits the chat, else the connection stays active ("Generally the web server does not terminate a connection after response data has been served to a client. The web server leaves the connection open such that if an event is received, it can immediately be sent to one or multiple clients. " Source: http://en.wikipedia.org/wiki/Push_technology#HTTP_server_push ), so a thread pool where each thread only handles one client wouldn't work in my opinion, or do you mean something else?

D.Unknown 2010-03-01 18:08:33

you didn't mention that you want to implement "Long living HTTP", or i didn't understand you :) personally i don't like this technology, because it is browser dependent. and it will require thread per client or you will have to implement complex logic with may be non-blocking sockets. basic HTTP + AJAX best fits for this task, IMHO

Andrey 2010-03-02 16:49:24

I know that ajax would be better but to have a chat without a lag you would have to make like 10 ajax requests per second, even if no one wrote something. I don't think that's possible and would require an own webserver too, if you don't want to save the messages to database and run a query 10 times a second per user..

D.Unknown 2010-03-03 12:22:27

Hey, yeah I understand this, but here is the same problem I told Andrey, - a http connection to this "chat server" will remain minutes or hours active and the task is always the same (user connects and the server sends content (html stream, not images or etc.) until it disconnects, no need to listen).you can't use a concept like other http servers do "10 threads in a pool, wait until a connection is closed and wait for a new one".

D.Unknown 2010-03-01 18:44:12

I just looked up how IRCd manage this problem and they seem not to use threads but send a new message to everyone in the room successive. And they aren't slow. Do you think this concept won't work on the server I want to program?

D.Unknown 2010-03-01 19:36:59

ansaurus

tags:

views:

answers:

HTTP stream server: threads?

related questions