Re: Recv and fwding in multi-threaded sockets programming
From: Steve Horsley (shoot_at_the.moon)
Date: 03/01/04
- Next message: xarax: "Re: Weak references - I must be missing something..."
- Previous message: Christophe Vanfleteren: "Re: Where does odmg.jar come from?"
- In reply to: Johny Franslay: "Recv and fwding in multi-threaded sockets programming"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Mon, 01 Mar 2004 20:04:07 +0000
Johny Franslay wrote:
> Hi, I am new to socket programming in Java and I have a newbie question.
>
> I'm writing a P2P network where each node maintains 5 separate
> connections to 5 other nodes and each connection is maintained on a
> separate thread. When one of the connection receives a query message, it
> would forward it to the other 4 connections.
>
> So in short i would like each thread to do both of these without
> invoking any new thread:
> 1. listen for incoming message from peer and forward it to other thread.
> 2. listen for forwarded message from another thread and send it to the
> peer.
>
> My dilemma is in (1.) I use BufferedReader.readLine() function to wait
> for incoming msg from peer. But does readLine() blocks until an input is
> received? If so, that means it will keep waiting for input even though
> there's a msg ready to be forwarded from the other thread.
>
> Does anybody know of a good idea on how to solve this problem?
> Is there a more suitable way of waiting for socket input other than
> readLine() in this context?
> What's the best way of notifying and passing a message to other threads?
>
> Any help would be appreciated.
> Thanks in advance.
>
> -Johny
Have a look at java.nio, which allows asynchronous notifications of
available data. I haven't looked at it in detail myself yet, so I
can't say more.
The following applies if you don't use java.nio:
Any read will either block until data is available, or return after
a timeout. Neither will give good performance the way you are trying.
Instead of trying to pass the message to a blocked thread, why not
just write to the Writer? I don't really see why you want to hand
the data to another thread. Your listening thread can just recieve
the message and then write it to every other socket in turn.
The only problem with that is that a frozen peer will eventually
cause writes to block, and lock up your peer. So maybe you need
TWO threads per peer:
1: A listener that recieves messages and posts them to a queue for
every other peer. This spends most of its time blocked in a
socket read.
2: A sender that recieves messages from the queue and sends them
over the socket. This spends most of its time blocked waiting for
a message from the queue.
Now you can make the queue drop messages when it reaches a limit,
and there's no hangup in your app. If the sender blocks because
of a frozen peer, the queue drops messages without blocking
the other listener threads.
Steve
- Next message: xarax: "Re: Weak references - I must be missing something..."
- Previous message: Christophe Vanfleteren: "Re: Where does odmg.jar come from?"
- In reply to: Johny Franslay: "Recv and fwding in multi-threaded sockets programming"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
