What's the bandwidth of the data stream? If it's less than 1% of your LAN
bandwidth, you could still do it with TCP. Data coming from a serial port
could well be 0.1% the bandwith of a wireless LAN, so even serving 100
clients with a stream each would only consume 10% of your bandwidth. It's
a waste, but not a massive one.
My clients are on a local wi-fi network
What do you mean? If you mean if the sender should know when the message
is received, the aswer is no. The sender only needs to send data without
thinking about if they are received.
So it doesn't matter if some of the data gets lost?
If you can afford to lose some data, then look into multicast, definitely.
Here's the guide:
http://java.sun.com/docs/books/tutorial/networking/datagrams/broadcasting.html
It looks like it's very easy to do. Bear in mind that it's UDP, so it's
not reliable, and the packet size is limited to a bit less than the MTU of
your network - which for wireless ethernet is 2272 bytes, i believe.
If you need reliability, then the easiest thing to do is to use TCP.
To get reliable delivery using multicast - now that's hard. Several
protocols have been developed, but none are widespread, and i'm not aware
of proper java support for any of them. In an application like this, you
might just be able to build your own on top of multicast sockets. I'd
consider using multicast backed up by a per-client TCP connection: number
each packet, multicast them, and buffer them (up to a certain limit) on
the server; if a client detects that it's missed one, it can request it
over the TCP link from the server. You could do cleverer things, using a
sliding window for flow control and to regulate how much the server needs
to buffer, and doing retransmissions over multicast if several clients
report a loss, but for your application, i don't think that's necessary.
tom