Home > Archive > Smalltalk > April 2006 > Broadcast and multicast using VW Opentalk
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Broadcast and multicast using VW Opentalk
|
|
| enigmainorlando@aol.com 2006-04-14, 8:06 am |
| Hello,
Took a few suggestions from this group and decided to try out this
middleware instead of continuing to code up my own stuff. So far, so
good, and it seems to be a reasonable product thus far, at least for
what I'm doing with it right now. I got things working pretty quickly,
at any rate.
Question: I'm no network protocol guru by any means, having never done
client-server programming before. I'd like to be able to multicast or
broadcast data to multiple clients, instead of having to send the same
exact array of data to all of them seperately. Seems this would
increase performance, be simpler, and be the way to go, if it is
possible. Problem is, I'm not sure that multicast or broadcast can do
this in my situation. I'm as to whether this is only
plausible (or possible) on one's own personal network at home/office,
or whether it would work on clients over the internet.
I suppose the point is, the clients will be anywhere on the internet,
and they won't be on some "personal" (or private) network. Can I
broadast, multicast, or "other"cast to them, or do I have to send the
(same) data to each client seperately?
Thanks for all the help. This group is great.
| |
| Reinout Heeck 2006-04-14, 8:06 am |
| enigmainorlando@aol.com wrote:
>
> I suppose the point is, the clients will be anywhere on the internet,
> and they won't be on some "personal" (or private) network. Can I
> broadast, multicast, or "other"cast to them, or do I have to send the
> (same) data to each client seperately?
>
For general internet usage broadcast will not work for you (this is
usually limited to a single subnet).
Multicasting will work, because cleints explicitly subscribe to the
multicast group, however this will generally give you trouble when going
through firewalls. Another problem is that the delivery of multicast
packets is not guaranteed, you will need to implement your own
check-and-retry protocol if you need reliable delivery (don't go there
unless you understand how TCP does that and prevents network storms).
Here at Soops where we build stock- and powerexchange clients/servers we
use a single TCP connection per client (to avoid firewall and NAT
trouble), we multiplex our multicasted information onto that same
connection. This does give the duplication inefficiency you mention, but
we decided that a fatter pipe at the server end is less hassle than the
other solutions in terms of end user help requests.
HTH,
Reinout
-------
|
|
|
|
|