<p>I'm working on a .net solution that is run completely inside a single network. When users make a change to the system, I want to launch an announcement and have everyone else hear it and act accordingly.  Is there a way that we can broadcast out messages like this (like UDP will let you do) while keeping guaranteed delivery (like TCP)?</p>

<p>This is on a small network (30ish clients), if that would make a difference.</p>

[{'answer_id': 31575, 'author': 'Tim Williscroft', 'author_id': 2789, 'author_profile': 'https://Stackoverflow.com/users/2789', 'pm_score': -1, 'selected': False, 'text': '<p>do a RDP multicast. </p>\n'}, {'answer_id': 31579, 'author': 'paan', 'author_id': 2976, 'author_profile': 'https://Stackoverflow.com/users/2976', 'pm_score': 0, 'selected': False, 'text': '<p>What you can do is that after the broadcast  have the <strong>clients</strong> initiate the tcp connections. Otherwise you just have to keep a list of all clients and initiate the connections to each client yourself.</p>\n'}, {'answer_id': 31586, 'author': 'Ben Collins', 'author_id': 3279, 'author_profile': 'https://Stackoverflow.com/users/3279', 'pm_score': 0, 'selected': False, 'text': '<p>I think there are three options, broadly speaking:</p>\n\n<ol>\n<li>Instead of broadcasting UDP, you could create an entity (a thread, process, server, service, or whatever the thing is that exists in your solution) that keeps a list of subscribers and sends unicast UDP messages to them.</li>\n<li>Use UDP multicast, but you\'ll have to write some sort of mechanism that would take care of reliable delivery for you (i.e., retries, timeouts, etc).  This also means you have to get a reply from your clients.  </li>\n<li>If you\'re not afraid of experimental transport protocols, you might look <a href="http://tldp.org/HOWTO/Multicast-HOWTO-9.html" rel="nofollow noreferrer">here</a> for suggestions., </li>\n</ol>\n'}, {'answer_id': 31629, 'author': 'Cagatay', 'author_id': 3071, 'author_profile': 'https://Stackoverflow.com/users/3071', 'pm_score': 3, 'selected': False, 'text': '<p>You could use <a href="http://www.spread.org/" rel="noreferrer">Spread</a> to do group communication.</p>\n'}, {'answer_id': 31704, 'author': 'Steve M', 'author_id': 1693, 'author_profile': 'https://Stackoverflow.com/users/1693', 'pm_score': 1, 'selected': False, 'text': "<p>You could implement your own TCP-like behaviour at the application layer. </p>\n\n<p>So for instance, you'd send out the UDP broadcast, but then expect a reply response from each host. If you didn't get a response within X seconds, then send another and so on until reaching some sort of threshold. If the threshold is reached (i.e. the host didn't respond at all), then report an error.</p>\n\n<p>To do this though, you'd need a pre-defined list of hosts to expect the responses back from.</p>\n"}, {'answer_id': 31768, 'author': 'Sander', 'author_id': 2928, 'author_profile': 'https://Stackoverflow.com/users/2928', 'pm_score': 5, 'selected': True, 'text': '<p>Almost all games have a need for the fast-reacting properties (and to a lesser extent, the connectionless properties) of UDP and the reliability of TCP. What they do is they build their own reliable protocol on top of UDP. This gives them the ability to just burst packets to whereever and optionally make them reliable, as well.</p>\n\n<p>The reliable packet system is usually a simple retry-until-acknowledged system simpler than TCP but there are protocols which go way beyond what TCP can offer.</p>\n\n<p>Your situation sounds very simple. You\'ll probably be able to make the cleanest solution yourself - just make every client send back an "I heard you" response and have the server keep trying until it gets it (or gives up).</p>\n\n<p>If you want something more, most custom protocol libraries are in C++, so I am not sure how much use they\'ll be to you. However, my knowledge here is a few years old - perhaps some protocols have been ported over by now. Hmm... RakNet and enet are two C/C++ libraries that come to mind.</p>\n'}, {'answer_id': 31783, 'author': 'epatel', 'author_id': 842, 'author_profile': 'https://Stackoverflow.com/users/842', 'pm_score': 3, 'selected': False, 'text': '<p>Take a look at <a href="http://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol" rel="noreferrer">sctp</a> which has a combination of tcp and udp features. There is a windows <a href="http://www.sctp.be/sctplib/index.htm" rel="noreferrer">implementation</a> available.</p>\n'}, {'answer_id': 31784, 'author': 'Jorge Córdoba', 'author_id': 2695, 'author_profile': 'https://Stackoverflow.com/users/2695', 'pm_score': 0, 'selected': False, 'text': '<p>Yoy should take a look at the Norm (NACK-Oriented Reliable Multicast) specification. You can find <a href="http://cs.itd.nrl.navy.mil/work/norm/index.php" rel="nofollow noreferrer">information about Norm here</a>.</p>\n\n<blockquote>\n  <p>The NORM protocol is designed to\n  provide end-to-end reliable transport\n  of bulk data objects or streams over\n  generic IP multicast routing and\n  forwarding services. NORM uses a\n  selective, negative acknowledgement\n  (NACK) mechanism for transport\n  reliability and offers additional\n  protocol mechanisms to conduct\n  reliable multicast sessions with\n  limited "a priori" coordination among\n  senders and receivers</p>\n</blockquote>\n\n<p>It somewhat very well known in the military world.</p>\n\n<p><a href="http://cs.itd.nrl.navy.mil/pubs/docs/rfc3940.pdf" rel="nofollow noreferrer">Norm specs.</a></p>\n\n<p><a href="http://downloads.pf.itd.nrl.navy.mil/norm/" rel="nofollow noreferrer">Norm Source</a></p>\n'}, {'answer_id': 56216, 'author': 'Andrew Johnson', 'author_id': 5109, 'author_profile': 'https://Stackoverflow.com/users/5109', 'pm_score': 2, 'selected': False, 'text': '<p>@epatel - I second the SCTP suggestion (I voted up, but can\'t comment yet so additional stuff here).  </p>\n\n<p>SCTP has many great features and flexibility.  You can sub-divide your connection into multiple streams, and choose the reliablity of each and whether it is ordered or not.  Alternatively, with the <a href="http://www.ietf.org/rfc/rfc3758.txt" rel="nofollow noreferrer">Partially Reliability</a> extension, you can control reliability on a per message basis.</p>\n'}, {'answer_id': 81890, 'author': 'tialaramex', 'author_id': 9654, 'author_profile': 'https://Stackoverflow.com/users/9654', 'pm_score': 2, 'selected': False, 'text': '<p>Broadcast is not what you want. Since there could and probably will be devices attached to this network which don\'t care about your message, you should use Multicast. Unlike broadcast messages, which must be sent to and processed by every client on the network, Multicast messages are delivered only to interested clients (ie those which have some intention to receive this particular type of message and act on it).</p>\n\n<p>If you later scale this system up so that it needs to be routed over a large network, multicast can scale to that, whereas broadcast won\'t, so you gain a scalability benefit which you might appreciate later. Meanwhile you eliminate unnecessary overhead in switches and other devices that don\'t need to see these "something changed" messages.</p>\n'}, {'answer_id': 312593, 'author': 'Bruno Rijsman', 'author_id': 21435, 'author_profile': 'https://Stackoverflow.com/users/21435', 'pm_score': 2, 'selected': False, 'text': '<p>You might want to look into <a href="https://www.rfc-editor.org/rfc/rfc3208" rel="nofollow noreferrer">RFC 3208</a> &quot;PGM Reliable Transport Protocol Specification&quot;.</p>\n<p>Here is the abstract:</p>\n<blockquote>\n<p>Pragmatic General Multicast (PGM)\nis a reliable multicast transport<br />\nprotocol for applications that require\nordered or unordered,<br />\nduplicate-free, multicast data\ndelivery from multiple sources to<br />\nmultiple receivers.  PGM guarantees\nthat a receiver in the group    either\nreceives all data packets from\ntransmissions and repairs, or    is\nable to detect unrecoverable data\npacket loss.  PGM is    specifically\nintended as a workable solution for\nmulticast    applications with basic\nreliability requirements.  Its central\ndesign    goal is simplicity of\noperation with due regard for\nscalability and    network efficiency.</p>\n</blockquote>\n'}, {'answer_id': 354612, 'author': 'Libor', 'author_id': 30777, 'author_profile': 'https://Stackoverflow.com/users/30777', 'pm_score': 0, 'selected': False, 'text': '<p>Why build something from scratch if you can use library? Especially for such small project?</p>\n\n<p>Try use <a href="http://code.google.com/p/emcaster/" rel="nofollow noreferrer">Emcaster</a> which itself using reliable multicast messaging - PGM, is written in .NET and with full source. You will get nice pub/sub engine with topic filtering readily available. Or you can learn from code how to do it and base your own extension on it.</p>\n'}, {'answer_id': 354665, 'author': 'Szundi', 'author_id': 22631, 'author_profile': 'https://Stackoverflow.com/users/22631', 'pm_score': 0, 'selected': False, 'text': "<p>I think the most irritating feature of TCP in these scenarios is the ability/way of sorting incoming packets to their original order - the concept of a stream. You cannot read a byte until the byte before it arrived.</p>\n\n<p>If you can live without it, you have your chance to have your protocol, fast and reliable, but not for ordering of packets! It's simply impossible to manage both of them, because you cannot order your bytes until you receive an other copy of a lost packet, that's the main tradeoff.</p>\n"}, {'answer_id': 2099535, 'author': 'Matthew Herrmann', 'author_id': 232066, 'author_profile': 'https://Stackoverflow.com/users/232066', 'pm_score': 1, 'selected': False, 'text': "<p>Create a TCP server. Have each client connect. In your TCP protocol with the clients, create each packet with a 2-byte prefix of the total size of the following message.</p>\n\n<p>Clients then call <code>read(max_size=2)</code> on the socket to determine the size of the next message, and then <code>read(max_size=s)</code> to collect the message.</p>\n\n<p>You get reliable, ordered messages, simple. You don't need a messaging framework for this one.</p>\n"}, {'answer_id': 2099619, 'author': 'crowne', 'author_id': 97745, 'author_profile': 'https://Stackoverflow.com/users/97745', 'pm_score': 2, 'selected': False, 'text': '<p>You could use a Message Broker, such as <a href="http://activemq.apache.org/" rel="nofollow noreferrer">ActiveMQ</a>.<br>\nPublish your messages to a topic and have the clients register durable subscriptions to the topic, so that they won\'t miss any messages even if they are not online.  </p>\n\n<blockquote>\n  <p>Apache ActiveMQ is a message broker\n  written in Java together with a full\n  JMS client. However Apache ActiveMQ is\n  designed to communicate over a number\n  of protocols such as Stomp and\n  OpenWire together with supporting a\n  number of different language specific\n  clients.</p>\n</blockquote>\n\n<p>Client platform support includes c# and .net  </p>\n'}, {'answer_id': 28469462, 'author': 'Pacerier', 'author_id': 632951, 'author_profile': 'https://Stackoverflow.com/users/632951', 'pm_score': 1, 'selected': False, 'text': '<p>You\'d <strong>definitely</strong> want to look into <a href="https://en.wikipedia.org/wiki/Pragmatic_General_Multicast" rel="nofollow noreferrer">Pragmatic General Multicast</a>:</p>\n\n<blockquote>\n  <p>While TCP uses ACKs to acknowledge groups of packets sent (something that would be <strong>uneconomical over multicast</strong>), PGM uses the concept of Negative Acknowledgements (NAKs). </p>\n</blockquote>\n\n<p>For further G-diving, the term you\'re looking for is <a href="https://en.wikipedia.org/wiki/Reliable_multicast#Existing_or_proposed_protocols" rel="nofollow noreferrer">reliable multicast</a>.  Also take a look at <a href="https://en.wikipedia.org/wiki/Multipath_TCP" rel="nofollow noreferrer">Multipath TCP</a>.</p>\n'}]
['https://Stackoverflow.com/questions/31572', 'https://Stackoverflow.com', 'https://Stackoverflow.com/users/3259/']