Non-Blocking receive on MulticastSocket

[Ale]

Hi all!

How can I implement a non-blocking receive on a MulticastSocket object?

With socket objects it was simple:

socket = new Socket(hostIP, port);
in = new BufferedReader(new
InputStreamReader(socket.getInputStream()));
and so...


if (in.ready())
{// Receive data}

Thanks.

Ale

 

[EJP]

Hi all!

How can I implement a non-blocking receive on a MulticastSocket object?

if (in.ready())
{// Receive data}

That's not a great technique on a Socket btw, but you can get the effect
by setting a very short read timeout on a Socket, or a DatagramSocket or
MulticastSocket which extends it.

 

[Knute Johnson]

That's not a great technique on a Socket btw, but you can get the effect
by setting a very short read timeout on a Socket, or a DatagramSocket or
MulticastSocket which extends it.

The real question is why would you want to? There is nothing for the
read thread to do until the data packet arrives.

 

[EJP]

The real question is why would you want to? There is nothing for the
read thread to do until the data packet arrives.

Well we don't know what the OP is actually doing. He *might* be
simulating Selector.select() on MulticastSockets, as for some bizarre
reason Sun *still* haven't provided a selectable MulticastSocketChannel
despite the effort required being pretty trivial.

But I agree. I think I've seen exactly two valid uses for
ready()/available()/FIONREAD in about twenty years, and I can't remember
the other one.

 

[Ale]

I need to implement a chat using multicast and without using RMI or
other middlewares...

So if the user wants to write (send) a message, the chat client must
not block on receive... Am I in fault?

I think i'll set a short timeout on socket....

Thank you!

Ale

 

[Knute Johnson]

I need to implement a chat using multicast and without using RMI or
other middlewares...

So if the user wants to write (send) a message, the chat client must
not block on receive... Am I in fault?

I think i'll set a short timeout on socket....

Thank you!

Ale

That is not the most efficient way to solve your problem. Java is very
simple to multi-thread so what I would do is write a thread that is the
receiver and then use your GUI to be the transmitter. That way you can
receive data and send data at the same time.

 

[John Ersatznom]

...That way you can receive data and send data at the same time.

This idea, formally known as "full duplex", isn't exactly revolutionary.

 

[Knute Johnson]

This idea, formally known as "full duplex", isn't exactly revolutionary.

It is interesting though that the non-blocking I/O questions are usually
caused by not understanding this simple concept.