blocks|key|5172811|text|几乎所有游戏都需要UDP的快速反应特性(以及较少的无连接特性)和TCP的可靠性。他们所做的就是在UDP之上建立自己的可靠协议。这使它们能够仅将包突发到任何地方，并可选地使其可靠。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|5172812|可靠的分组系统通常是一个简单的重试直到确认的系统，比TCP更简单，但也有一些协议远远超出了TCP所能提供的范围。|5172813|你的情况听起来很简单。你也许能够自己做出最干净的解决方案--只要让每个客户发回一个“我听到了”的响应，然后让服务器继续尝试，直到它得到它(或者放弃)。|5172814|如果你想要更多的东西，大多数自定义协议库都在C%2B%2B中，所以我不确定它们对你有多大的用处。然而，我在这里的知识是几年前的--也许现在已经移植了一些协议。嗯..。RakNet和enet是脑海中浮现的两个C/C%2B%2B库。|5172815|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

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.

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.

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).

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.

blocks|key|5172866|text|看看sctp，它结合了tcp和udp特性。有windows+implementation可用。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|5172867|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol|1|http://www.sctp.be/sctplib/index.htm^0|2|4|0|U|E|1|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@$A|O|B|P|1|Q]|$A|R|B|S|1|T]]|C|$]]|$1|D|3|-4|5|6|7|U|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]|L|$5|G|H|I|C|$J|M]]]]

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.

blocks|key|2917356|text|您可以使用Spread进行群组通信。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|2917357|entityMap|0|LINK|mutability|MUTABLE|url|http://www.spread.org/^0|5|6|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

You could use <a href="http://www.spread.org/" rel="noreferrer">Spread</a> to do group communication.

blocks|key|5173046|text|@epatel+-我赞同SCTP的建议(我投了赞成票，但不能在这里评论这么多额外的东西)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|5173047|SCTP具有许多强大的功能和灵活性。您可以将连接细分为多个流，并选择每个流的可靠性以及是否排序。或者，使用Partially+Reliability扩展，您可以在每个消息的基础上控制可靠性。|offset|length|5173048|entityMap|0|LINK|mutability|MUTABLE|url|http://www.ietf.org/rfc/rfc3758.txt^0|0|1H|L|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@$D|P|E|Q|1|R]]|A|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|A|$]]]|G|$H|$5|I|J|K|A|$L|M]]]]

@epatel - I second the SCTP suggestion (I voted up, but can't comment yet so additional stuff here). 

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.

blocks|key|2917750|text|广播不是你想要的。由于可能会有设备连接到此网络，而这些设备并不关心您的消息，因此您应该使用多播。与广播消息不同，广播消息必须发送到网络上的每个客户端并由其处理，而多播消息仅发送到感兴趣的客户端(即那些有某种意图接收这种特定类型的消息并对其采取行动的客户端)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2917751|如果您稍后扩展此系统，以便需要在大型网络上路由它，则多播可以扩展到这种规模，而广播则不会，因此您获得了一个可伸缩性好处，稍后您可能会欣赏到这一点。同时，您消除了交换机和其他设备中不必要的开销，这些设备不需要看到这些“某些改变”的消息。|2917752|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

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).

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.

blocks|key|3762270|text|你可能想看看RFC+3208+"PGM可靠传输协议规范“。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|3762271|摘要如下：|3762272|3762273|实用通用组播是一种可靠的组播传输方式|blockquote|3762274|3762275|用于需要有序或无序的应用程序的协议，|3762276|无重复的组播数据从多个源传送到|3762277|多个接收器。PGM保证组中的接收器或者接收来自传输和修复的所有数据分组，或者能够检测不可恢复的数据分组丢失。PGM专门用作具有基本可靠性要求的组播应用的可行解决方案。它的核心设计目标是操作简单，并适当考虑可伸缩性和网络效率。|3762278|entityMap|0|LINK|mutability|MUTABLE|url|https://www.rfc-editor.org/rfc/rfc3208^0|6|8|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Y|8|@]|9|@$A|Z|B|10|1|11]]|C|$]]|$1|D|3|E|5|6|7|12|8|@]|9|@]|C|$]]|$1|F|3|-4|5|6|7|13|8|@]|9|@]|C|$]]|$1|G|3|H|5|I|7|14|8|@]|9|@]|C|$]]|$1|J|3|-4|5|6|7|15|8|@]|9|@]|C|$]]|$1|K|3|L|5|6|7|16|8|@]|9|@]|C|$]]|$1|M|3|N|5|6|7|17|8|@]|9|@]|C|$]]|$1|O|3|P|5|6|7|18|8|@]|9|@]|C|$]]|$1|Q|3|-4|5|6|7|19|8|@]|9|@]|C|$]]]|R|$S|$5|T|U|V|C|$W|X]]]]

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;.
Here is the abstract:
<blockquote>
Pragmatic General Multicast (PGM)
is a reliable multicast transport 
protocol for applications that require
ordered or unordered, 
duplicate-free, multicast data
delivery from multiple sources to 
multiple receivers. PGM guarantees
that a receiver in the group either
receives all data packets from
transmissions and repairs, or is
able to detect unrecoverable data
packet loss. PGM is specifically
intended as a workable solution for
multicast applications with basic
reliability requirements. Its central
design goal is simplicity of
operation with due regard for
scalability and network efficiency.
</blockquote>

blocks|key|5173429|text|您可以使用消息代理，例如ActiveMQ。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|5173430|将您的消息发布到一个主题，并让客户端注册对该主题的持久订阅，这样即使消息不在线，它们也不会错过任何消息。|5173431|JMS是一个用|5173432|编写的消息代理和一个完整的ActiveMQ客户端。但是，Apache被设计为通过许多协议进行通信，例如ActiveMQ和OpenWire，同时还支持许多不同语言特定的客户端。|blockquote|5173433|5173434|5173435|客户端平台支持包括c#和.net|5173436|entityMap|0|LINK|mutability|MUTABLE|url|http://activemq.apache.org/^0|C|8|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|W|8|@]|9|@$A|X|B|Y|1|Z]]|C|$]]|$1|D|3|E|5|6|7|10|8|@]|9|@]|C|$]]|$1|F|3|G|5|6|7|11|8|@]|9|@]|C|$]]|$1|H|3|I|5|J|7|12|8|@]|9|@]|C|$]]|$1|K|3|-4|5|6|7|13|8|@]|9|@]|C|$]]|$1|L|3|-4|5|6|7|14|8|@]|9|@]|C|$]]|$1|M|3|N|5|6|7|15|8|@]|9|@]|C|$]]|$1|O|3|-4|5|6|7|16|8|@]|9|@]|C|$]]]|P|$Q|$5|R|S|T|C|$U|V]]]]

You could use a Message Broker, such as <a href="http://activemq.apache.org/" rel="nofollow noreferrer">ActiveMQ</a>. 
Publish 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. 

<blockquote>
 Apache ActiveMQ is a message broker
 written in Java together with a full
 JMS client. However Apache ActiveMQ is
 designed to communicate over a number
 of protocols such as Stomp and
 OpenWire together with supporting a
 number of different language specific
 clients.
</blockquote>

Client platform support includes c# and .net

blocks|key|5172707|text|您可以在应用层实现自己的类似TCP的行为。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|5172708|例如，您将发出UDP广播，但随后会收到来自每台主机的回复响应。如果您在X秒内没有收到响应，则发送另一个响应，依此类推，直到达到某种阈值。如果达到阈值(即主机根本没有响应)，则报告错误。|5172709|然而，要做到这一点，您需要一个预定义的主机列表，以期待从其返回响应。|5172710|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

You could implement your own TCP-like behaviour at the application layer. 

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.

To do this though, you'd need a pre-defined list of hosts to expect the responses back from.

blocks|key|5173399|text|创建TCP服务器。让每个客户端都进行连接。在与客户端的TCP协议中，使用以下消息总大小的2字节前缀创建每个数据包。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|5173400|然后，客户端调用套接字上的read(max_size=2)来确定下一条消息的大小，然后调用read(max_size=s)来收集消息。|offset|length|style|CODE|5173401|您可以获得可靠、有序的消息，非常简单。你不需要一个消息传递框架就可以了。|5173402|entityMap^0|0|D|G|19|G|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@$D|N|E|O|F|G]|$D|P|E|Q|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|R|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|S|8|@]|9|@]|A|$]]]|K|$]]

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.

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.

You get reliable, ordered messages, simple. You don't need a messaging framework for this one.

blocks|key|3762695|text|你肯定会想要调查Pragmatic+General+Multicast|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|3762696|3762697|使用ACK来确认发送的分组(这在多播上是不经济的)，而PGM使用否定确认(NAK)的概念。|blockquote|3762698|3762699|3762700|对于进一步的G-diving，你要找的术语是reliable+multicast。还可以看看Multipath+TCP。|3762701|entityMap|0|LINK|mutability|MUTABLE|url|https://en.wikipedia.org/wiki/Pragmatic_General_Multicast|1|https://en.wikipedia.org/wiki/Reliable_multicast#Existing_or_proposed_protocols|2|https://en.wikipedia.org/wiki/Multipath_TCP^0|8|R|0|0|0|0|0|0|M|I|1|1A|D|2|0^^$0|@$1|2|3|4|5|6|7|X|8|@]|9|@$A|Y|B|Z|1|10]]|C|$]]|$1|D|3|-4|5|6|7|11|8|@]|9|@]|C|$]]|$1|E|3|F|5|G|7|12|8|@]|9|@]|C|$]]|$1|H|3|-4|5|6|7|13|8|@]|9|@]|C|$]]|$1|I|3|-4|5|6|7|14|8|@]|9|@]|C|$]]|$1|J|3|K|5|6|7|15|8|@]|9|@$A|16|B|17|1|18]|$A|19|B|1A|1|1B]]|C|$]]|$1|L|3|-4|5|6|7|1C|8|@]|9|@]|C|$]]]|M|$N|$5|O|P|Q|C|$R|S]]|T|$5|O|P|Q|C|$R|U]]|V|$5|O|P|Q|C|$R|W]]]]

You'd definitely want to look into <a href="https://en.wikipedia.org/wiki/Pragmatic_General_Multicast" rel="nofollow noreferrer">Pragmatic General Multicast</a>:

<blockquote>
 While TCP uses ACKs to acknowledge groups of packets sent (something that would be uneconomical over multicast), PGM uses the concept of Negative Acknowledgements (NAKs). 
</blockquote>

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>.

blocks|key|5172520|text|您可以做的是在广播之后让客户端发起tcp连接。否则，您只需保留所有客户端的列表，并自行启动到每个客户端的连接。|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|5172521|entityMap^0|C|3|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|K|8|@]|D|@]|E|$]]]|G|$]]

What you can do is that after the broadcast have the clients initiate the tcp connections. Otherwise you just have to keep a list of all clients and initiate the connections to each client yourself.

blocks|key|3761765|text|从广义上讲，我认为有三种选择：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3761766|3761767|与广播UDP不同，你可以创建一个实体(线程，进程，服务器，服务，或者任何存在于你的解决方案中的东西)来保存用户列表并向他们发送单播UDP消息。|ordered-list-item|3761768|使用UDP多播，但是你必须编写某种机制来为你提供可靠的传送(即重试，超时等)。这也意味着你必须得到客户的回复。|3761769|如果你不怕实验性的传输协议，你可以在here上寻求建议。，|offset|length|3761770|3761771|entityMap|0|LINK|mutability|MUTABLE|url|http://tldp.org/HOWTO/Multicast-HOWTO-9.html^0|0|0|0|0|I|4|0|0|0^^$0|@$1|2|3|4|5|6|7|U|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|V|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|W|8|@]|9|@]|A|$]]|$1|F|3|G|5|E|7|X|8|@]|9|@]|A|$]]|$1|H|3|I|5|E|7|Y|8|@]|9|@$J|Z|K|10|1|11]]|A|$]]|$1|L|3|-4|5|6|7|12|8|@]|9|@]|A|$]]|$1|M|3|-4|5|6|7|13|8|@]|9|@]|A|$]]]|N|$O|$5|P|Q|R|A|$S|T]]]]

I think there are three options, broadly speaking:

<ol>
<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>
<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>
<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>
</ol>

blocks|key|711496|text|Yoy应该看看Norm+(面向NACK的可靠多播)规范。你可以找到information+about+Norm+here。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|711497|711498|是一种标准协议，旨在通过通用IP组播路由和转发服务提供大量数据对象或流的端到端可靠传输。NORM使用选择性否定确认(NACK)机制来实现传输可靠性，并提供额外的协议机制来进行可靠的多播会话，在发送者和接收者之间进行有限的“先验”协调|blockquote|711499|711500|711501|它在军事世界中有点非常出名。|711502|Norm+specs.|711503|Norm+Source|711504|entityMap|0|LINK|mutability|MUTABLE|url|http://cs.itd.nrl.navy.mil/work/norm/index.php|1|http://cs.itd.nrl.navy.mil/pubs/docs/rfc3940.pdf|2|http://downloads.pf.itd.nrl.navy.mil/norm/^0|X|R|0|0|0|0|0|0|0|0|B|1|0|0|B|2|0^^$0|@$1|2|3|4|5|6|7|11|8|@]|9|@$A|12|B|13|1|14]]|C|$]]|$1|D|3|-4|5|6|7|15|8|@]|9|@]|C|$]]|$1|E|3|F|5|G|7|16|8|@]|9|@]|C|$]]|$1|H|3|-4|5|6|7|17|8|@]|9|@]|C|$]]|$1|I|3|-4|5|6|7|18|8|@]|9|@]|C|$]]|$1|J|3|K|5|6|7|19|8|@]|9|@]|C|$]]|$1|L|3|M|5|6|7|1A|8|@]|9|@$A|1B|B|1C|1|1D]]|C|$]]|$1|N|3|O|5|6|7|1E|8|@]|9|@$A|1F|B|1G|1|1H]]|C|$]]|$1|P|3|-4|5|6|7|1I|8|@]|9|@]|C|$]]]|Q|$R|$5|S|T|U|C|$V|W]]|X|$5|S|T|U|C|$V|Y]]|Z|$5|S|T|U|C|$V|10]]]]

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>.

<blockquote>
 The NORM protocol is designed to
 provide end-to-end reliable transport
 of bulk data objects or streams over
 generic IP multicast routing and
 forwarding services. NORM uses a
 selective, negative acknowledgement
 (NACK) mechanism for transport
 reliability and offers additional
 protocol mechanisms to conduct
 reliable multicast sessions with
 limited "a priori" coordination among
 senders and receivers
</blockquote>

It somewhat very well known in the military world.

<a href="http://cs.itd.nrl.navy.mil/pubs/docs/rfc3940.pdf" rel="nofollow noreferrer">Norm specs.</a>

<a href="http://downloads.pf.itd.nrl.navy.mil/norm/" rel="nofollow noreferrer">Norm Source</a>

blocks|key|3762392|text|如果你可以使用库，为什么要从头开始构建呢？尤其是对于这么小的项目？|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3762393|尝试使用Emcaster，它本身使用可靠的多播消息传递-+PGM，是用.NET编写的，并且具有完整的源代码。你会得到一个很好的发布/订阅引擎，主题过滤很容易就能用到。或者，您可以从代码中学习如何做到这一点，并在此基础上进行自己的扩展。|offset|length|3762394|entityMap|0|LINK|mutability|MUTABLE|url|http://code.google.com/p/emcaster/^0|0|4|8|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@$D|P|E|Q|1|R]]|A|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|A|$]]]|G|$H|$5|I|J|K|A|$L|M]]]]

Why build something from scratch if you can use library? Especially for such small project?

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.

blocks|key|2917990|text|我认为TCP在这些场景中最令人恼火的功能是将传入的数据包排序为其原始顺序的能力/方式-流的概念。只有在字节到达之前，才能读取该字节。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2917991|如果你可以没有它，你就有机会拥有你的协议，快速和可靠，但不是为了数据包的排序！要同时管理它们是不可能的，因为在收到丢失数据包的另一个副本之前，您无法对您的字节进行排序，这是主要的权衡。|2917992|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

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.

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.

blocks|key|5172393|text|执行RDP组播。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|5172394|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

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)?

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

Broadcast like UDP with the reliability of TCP

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云AI代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

功能1上新10个字符

功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符。

功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符。

功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符

功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符

功能4上新

文章&问答评论现已支持表情

全新交互，全新视觉，新增快捷键、悬浮工具栏、高亮块等功能并同时优化现有功能，全面提升创作效率和体验

社区富文本编辑器全新改版！诚邀体验～ 

精选全网热门MCP server，让你的AI更好用 🚀

💥开发者 MCP广场重磅上线！

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

我正在开发一个完全在单个网络中运行的.net解决方案。当用户对系统进行更改时，我希望启动一个公告，并让其他所有人都听到它并采取相应的行动。有没有一种方法可以让我们广播出这样的消息(就像UDP允许的那样)，同时保持有保证的传输(比如TCP)？这是在一个小网络上(30多个客户端)，如果这会有所不同的话。

问像UDP一样广播，具有TCP的可靠性
EN

回答 16

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问像UDP一样广播，具有TCP的可靠性EN

回答 16

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问像UDP一样广播，具有TCP的可靠性
EN