Register | Login
Views: 19364387
Main | Memberlist | Active users | ACS | Commons | Calendar | Online users
Ranks | FAQ | Color Chart | Photo album | IRC Chat
11-02-05 12:59 PM
0 user currently in Programming. | 3 guests
Acmlm's Board - I2 Archive - Programming - Java Project Question | |
Add to favorites | "RSS" Feed | Next newer thread | Next older thread
User Post
Kasumi-Astra
Administrator
Level: 62

Posts: 1233/1867
EXP: 1971846
For next: 12840

Since: 03-15-04
From: Reading, UK
Uni: Sheffield, UK

Since last post: 1 day
Last activity: 12 hours
Posted on 02-24-05 01:52 AM Link | Quote
In my latest Java assignment, we've been given the challenge to write the code for a chat-room client and server.

We're using multi-threading techniques, and my server program uses one thread for every client to recieve a message and echo a message back to the same client program. Unfortunately, I'm having problems getting each thread to echo messages sent in across all sockets (used in other threads) so that every message sent in is displayed on all clients.
My idea was to keep a vector of clients that stored their screen name and socket, and have it available to every thread object, but every strategy I try doesn't work. Has anyone got any ideas about how I can approach this problem?
HyperLamer
<||bass> and this was the soloution i thought of that was guarinteed to piss off the greatest amount of people

Sesshomaru
Tamaranian

Level: 118

Posts: 3435/8210
EXP: 18171887
For next: 211027

Since: 03-15-04
From: Canada, w00t!
LOL FAD

Since last post: 2 hours
Last activity: 2 hours
Posted on 02-24-05 03:10 AM Link | Quote
Well I'm not sure how you would do it in Java, but I made a really simple, single-threaded version of this in VB once. Basically the server keeps an array of each IP and the corresponding name, and when it recieves a message it loops through them all and sends it to them, including the one it came from (don't have the clients echo the messages they send). You could also have the client attatch the name, but in a large-scale system it's a lot easier to exploit, and since it's barely any difference in code to have the server do it, you may as well.
sloat

Level: 16

Posts: 35/85
EXP: 18044
For next: 2212

Since: 05-21-04
From: South Central Delaware

Since last post: 19 days
Last activity: 5 hours
Posted on 02-24-05 08:16 AM Link | Quote
I did this same thing for my final project in java. What I did was make a class that extends the Thread class and had public variables for the socket, and the Object Input/Output streams. In the Server class, i kept a linked list of all the threads i had created, and when i wanted to broadcast a message, i looped through the list and wrote the data directly to the output stream. iirc, it wouldn't have worked correctly if i didn't use the 'synchronized' modifier on my broadcastMsg function. basically you want to put that on all the functions that'll have access to the thread data.


(edited by sloat on 02-23-05 11:17 PM)
Kasumi-Astra
Administrator
Level: 62

Posts: 1237/1867
EXP: 1971846
For next: 12840

Since: 03-15-04
From: Reading, UK
Uni: Sheffield, UK

Since last post: 1 day
Last activity: 12 hours
Posted on 02-24-05 03:28 PM Link | Quote
I don't think I'll actually need syncronised, as two threads will not be waiting on two different pieces of information that the other requires. Ie, I don't think there's any potential for deadlock.

At the moment, I've got a new idea that I'm going to try this afternoon... I'm going to create a outputter class and create an instance of it. Whenever a new client joins, a new thread object is created to handle the inputs, and a method is called for the outputter object to add a new client object to it. Basically, whenever an input is recieved, a method is called pass the message to the outputter object, and send it to all the clients.
Fingers crossed, I guess
Add to favorites | "RSS" Feed | Next newer thread | Next older thread
Acmlm's Board - I2 Archive - Programming - Java Project Question | |


ABII


AcmlmBoard vl.ol (11-01-05)
© 2000-2005 Acmlm, Emuz, et al



Page rendered in 0.021 seconds.