|
19 May 2003, 19:23
|
#1
|
Rawr rawr
Join Date: Dec 2000
Location: Upside down
Posts: 5,300
|
Networking & threads
If you have a server, that relays data to an amount of clients, is it smart to give each socket to a client it's own thread?
My receive-function works all sockets in one thread. Is this also acceptable for sending data?
|
|
|
19 May 2003, 19:39
|
#2
|
NEWSBOT
Join Date: Dec 2000
Location: The enby cave!
Posts: 4,872
|
Re: Networking & threads
Quote:
Originally posted by Structural Integrity
If you have a server, that relays data to an amount of clients, is it smart to give each socket to a client it's own thread?
My receive-function works all sockets in one thread. Is this also acceptable for sending data?
|
i'd say it depends on the function of the server, also depends how many clients there are, and how fast the data is needed etc.
|
|
|
19 May 2003, 19:44
|
#3
|
Ball
Join Date: Oct 2001
Posts: 4,410
|
Re: Networking & threads
Quote:
Originally posted by Structural Integrity
If you have a server, that relays data to an amount of clients, is it smart to give each socket to a client it's own thread?
|
What language? OS? What are your design goals?
I like doing everything in one thread when I'm using C. But if I was writing something professionally I'd add support for SMP, and have dozens of other considerations. There are various threading models for concurrent servers like fork, pre-fork, select, and more complex hybrids. Single threaded is fine most of the time.
Quote:
My receive-function works all sockets in one thread. Is this also acceptable for sending data?
|
Yes, it should be.
|
|
|
19 May 2003, 19:45
|
#4
|
Henry Kelly
Join Date: Apr 2000
Posts: 7,374
|
It makes sense insofaras you could emulate non-blocking socket routines using threads calling blocking socket routines, just set up some callbacks and huzzah.
Most FTP proggies and the like make use of multithreaded sockets, so it can't be all bad.
__________________
You're now playing ketchup
|
|
|
19 May 2003, 20:13
|
#5
|
Rawr rawr
Join Date: Dec 2000
Location: Upside down
Posts: 5,300
|
I got this "chat application" in java from someone from school in my hands to work further on, and it's a damn mess.
He uses objects that have sockets in them ("ClientWorkers" he calls them). These objects are runnable (meaning that they can be threaded, for those not familiar with java). Now I was wondering if they should be threaded AT ALL.
I can just relay all data in one loop in one thread. Atleast that's what I thought. But this got me thinking... doesn't this block the whole app if some client dies?
|
|
|
19 May 2003, 20:17
|
#6
|
Born Sinful
Join Date: Nov 2000
Location: Loughborough, UK
Posts: 4,059
|
timeouts?
__________________
Worth dying for. Worth killing for. Worth going to hell for. Amen.
|
|
|
19 May 2003, 20:18
|
#7
|
Henry Kelly
Join Date: Apr 2000
Posts: 7,374
|
If you're using non-blocking socket IO then a client dying shouldn't be an issue; you've just got to make room in your IO cycle to ping that client and remember to kill it off if it doesn't respond.
Threading would make that easier, have each client get a dedicated thread and let the threads get on with the work themselves. It saves you some thought on the implementation.
__________________
You're now playing ketchup
|
|
|
19 May 2003, 20:38
|
#8
|
Rawr rawr
Join Date: Dec 2000
Location: Upside down
Posts: 5,300
|
Quote:
Originally posted by meglamaniac
timeouts?
|
Yeah, well... that's all nice and dandy, but rather unpretty. What's the timeout time of a TCP socket? 30 seconds?
I made a TCP module in C++ intended for games, but I don't want it to block for half a minute when some client dies.
OK, so threading the stuff is a must. I'll have to rewrite my damn module then. =/
|
|
|
19 May 2003, 20:48
|
#9
|
Henry Kelly
Join Date: Apr 2000
Posts: 7,374
|
Does UDP actually block?
__________________
You're now playing ketchup
|
|
|
19 May 2003, 21:03
|
#10
|
Rawr rawr
Join Date: Dec 2000
Location: Upside down
Posts: 5,300
|
Quote:
Originally posted by pablissimo
Does UDP actually block?
|
UDP doesn't work with a permanent connection. It just sends stuff and hopes it reaches the client. I dunno if it block or not. I never worked with it.
But why are you suggesting UDP? For this game thing?
I don't think I want that. It's not intended for shooters, but for a strategy thingy. I want to make 100% sure my data arrives correctly. UDP doesn't guarantee that.
|
|
|
19 May 2003, 21:04
|
#11
|
Henry Kelly
Join Date: Apr 2000
Posts: 7,374
|
Ah.
Granted the only games I've coded were in mIRC but I always end up using UDP simply because of the performance increase.
You win this round.
__________________
You're now playing ketchup
|
|
|
19 May 2003, 21:26
|
#12
|
Spelling is for pussies
Join Date: Mar 2003
Location: Actually, where the feck am I........?
Posts: 446
|
Actually I think quite a few games do use UDP, for many reasons. And to get round the 'fire and forget' method of communication you use numbered packets, with re-sends for lost packets.
__________________
If God made me in his image, he's one fat ugly biatch.
I always get the soggy biscuit
Veni Vidi Codi
|
|
|
20 May 2003, 05:36
|
#13
|
Gubbish
Join Date: Sep 2000
Location: #FoW
Posts: 2,323
|
I've never ever lost an udp packet. The "no guarantee of arrival" crap is just ass-covering.
__________________
Gubble gubble gubble gubble
|
|
|
26 May 2003, 00:03
|
#14
|
/dev/zero Retired Mod
Join Date: May 2000
Posts: 415
|
If you are doing this in Java, and the target platform is not linux*, I'd definately implement some threading. If I was doing it, I'd have a dispatcher thread, and some worker threads. Pre-fork a certain number of workers and then grow your thread pool up to whatever limit you feel is necessary.
As each new connection arrives in your dispatcher, find the first worker thread thats not doing anything (usually test to see if it has a null socket), and assign it the new connection. If you cant find one, but find a null reference, create a new worker and replace the null reference. If you cant do any of them at all, the option is to exceed your worker count, or block. In pseudo code
Code:
Dispatcher
WorkerThread[] workers;
while (true) {
socket = getsocket(); //blocking call
WorkerThread worker;
for (i=0;i<workers.length;i++) {
worker = workers[i];
if (worker==null) {
workers[i] = new WorkerThread(socket).start();
break;
}
if (worker.socket == null)
worker.socket = socket;
worker.notify();
break;
}
}
}
Code:
WorkerThread
while (true) {
if(socket==null) {
try {
this.sleep(1000);
}
catch (InterruptedException ex) { }
}
else {
doWork();
socket=null;
}
}
OK, so my pseudo code looks a lot like Java .... you can do some more complicated and fancy things with Java, I think theparticle had a good example of a threadpool on his site - www.theparticle.com
* IMHO, Linux doesnt have great threading support, and java vm's under linux have even worse threading. Just my opinion, and based upon observation rather than fact. Java threads on solaris, however.. pretty fking good.
__________________
#linux : Home of Genius
<idimmu> ok i was chained to a desk with this oriental dude
|
|
|
26 May 2003, 00:12
|
#15
|
/dev/zero Retired Mod
Join Date: May 2000
Posts: 415
|
cant seem to find it there, but a good one shouldnt be hard to come by.
Google, as always, is your friend.
__________________
#linux : Home of Genius
<idimmu> ok i was chained to a desk with this oriental dude
|
|
|
26 May 2003, 01:19
|
#16
|
Friendly geek of GD :-/
Join Date: Nov 2000
Location: On my metal roid
Posts: 923
|
Quote:
Originally posted by W
I've never ever lost an udp packet. The "no guarantee of arrival" crap is just ass-covering.
|
FFS but it ISN'T guaranteed... It's like saying: " Smoking coses cancer? Bull****, I got a grandfather who smoked 40 cigarettes a day and still turned 90".
Sure, you can say, during these days, you trust the internet and its backbone, but since no "ACK - message received"-packet of any type is sent, you just cannot be sure wethere your original packet came through or not -- face it!!!
Implementing a protocol that relies on UDP messages that are essential wouldn't be a good idea...
Even if your experimental values showed a success-rate of 99.9%.
__________________
[ »] Entropy increases! :-/
|
|
|
26 May 2003, 18:29
|
#17
|
NEWSBOT
Join Date: Dec 2000
Location: The enby cave!
Posts: 4,872
|
Quote:
Originally posted by JetLinus
Implementing a protocol that relies on UDP messages that are essential wouldn't be a good idea...
Even if your experimental values showed a success-rate of 99.9%.
|
sure it would.
as mentioned, you just give each one a number, and if your missing one, get it resent..
__________________
[20:27:47] <nodrog-aawy> **** i think my housemate just caught me masturbating
[11:25:32] <idimmu> you are a little piggy arent you
[13:17:00] <KaneED> i'm so closet i'm like narnia
__________________
Pretty parks and funky scrap metal things here
|
|
|
26 May 2003, 18:31
|
#18
|
Henry Kelly
Join Date: Apr 2000
Posts: 7,374
|
Quote:
Originally posted by NEWSBOT3
sure it would.
as mentioned, you just give each one a number, and if your missing one, get it resent..
|
This is what TCP will do all on its own though, at a slight performance hit, so what's the point?
__________________
You're now playing ketchup
|
|
|
28 May 2003, 16:44
|
#19
|
Gubbish
Join Date: Sep 2000
Location: #FoW
Posts: 2,323
|
Quote:
Originally posted by JetLinus
FFS but it ISN'T guaranteed... It's like saying: "Smoking coses cancer? Bull****, I got a grandfather who smoked 40 cigarettes a day and still turned 90".
Sure, you can say, during these days, you trust the internet and its backbone, but since no "ACK - message received"-packet of any type is sent, you just cannot be sure wethere your original packet came through or not -- face it!!!
Implementing a protocol that relies on UDP messages that are essential wouldn't be a good idea...
Even if your experimental values showed a success-rate of 99.9%.
|
You don't understand. Nothing is guaranteed. You can employ whatever resending scheme you like, and you cannot give any guarantee. UDP is as safe as TCP, except in the utterly utterly rare cases of a link almost working correctly.
__________________
Gubble gubble gubble gubble
|
|
|
14 Jun 2003, 19:58
|
#20
|
Guest
|
responding to the original question, i did almost the exact same thing in Java for a few reasons:
a) When your thread blocks on an input read, doesn't block your server
b) When a client disconnects, your thread can kill itself and inform the main server it no longer exists (means less exception handling at the top layer)
c) You can make buffer classes to run between main server and the client threads if you ever think you could run into insane data transfers (should never be an issue though)
As to the multi-threading being a mess ... shouldn't have to be if you have a clear idea in mind when you go in to build
|
|
|
Thread Tools |
|
Display Modes |
Linear Mode
|
|
All times are GMT +1. The time now is 06:17.
| |