我有一个应用程序使用TCP套接字来交换字节数组，这些数组在大多数情况下包含JSON字符串数据。我遇到的是，对于较大的消息和不太理想的网络条件，使用NetworkStream.DataAvailable似乎不是检测消息结束的可靠方法。似乎在某些情况下DataAvailable被设置为false，即使只有部分消息已被对等方传输(使用TcpClient.GetStream().Write(data,0,data.Length)。这会导致不完整的数据被传回应用程序，在JSON消息的情况下，这意味着反序列化失败。我尝试了两种表现出相同问题的实现:实现1:byte[]Data;byte[]buff

我现在正在学习网络类(class)，并试图了解这三种协议(protocol)的用处。我知道他们正在努力使不可靠的链路层(IP)变得可靠。它们实际上在任何地方实现吗？TCP是否实现了其中的任何一个？就此而言，除了TCP和UDP之外，还有其他协议(protocol)在传输层上运行吗？我正在使用Kurose&Ross的《ComputerNetworking》一书。非常感谢任何帮助! 最佳答案 “三个协议(protocol)用在什么地方，我理解他们是在努力让不可靠的链路层(IP)变得可靠。”首先，不要将RDT与GBN和SR混淆，因为GBN和

我无法弄清楚一件事。RFC2616in4.4.5声明消息长度可以“通过服务器关闭连接。”确定。这意味着，服务器响应(例如返回大图像)是有效的，响应中没有Content-Lengthheader，但客户端应该保持获取直到连接关闭，然后假设所有数据都已下载。但是客户端如何确定连接是服务器故意关闭的呢？服务器应用程序可能在发送数据的过程中崩溃，服务器的操作系统很可能会发送FIN数据包以正常关闭与客户端的TCP连接。 最佳答案 你是对的，那个机制是完全不可靠的。这包含在RFC7230中:Sincethereisnowaytodistingu

我一直在编写服务器-客户端应用程序。服务器是用c#编写的，客户端代码是用java编写的。通信协议(protocol)是TCP。使用tcp传输文件时，可能会发送丢失的数据。换句话说，tcp是否保证数据正确到达。(我是否应该发送此文件的header信息以检查错误，如文件大小、哈希等) 最佳答案 可靠的tcp传输os的包排序。例如，您的tcp消息分为三个包A、B和C。您的客户端收到A，包B丢失，然后客户端收到C。在流中，您将仅获得包A，包C被存储，一旦包B被您的客户端重新传输和接收，在流中您将获得包B，然后是C。如果包B通过另一种方式路由

我需要每秒将1000个小对象从服务器程序推送到千兆局域网上的100个客户端，所以我需要最快的方法，谢谢。我知道usp和TCP之间的区别-我在udp之上有一个层以使其可靠和有序。我应该使用哪个，为什么？Udp单播或TCP。由于路由器原因，我无法使用Udp多播。谢谢 最佳答案 客户端之间可以相互通信吗？最终，您的服务器只有有限数量的电线，这限制了您的速度。让客户端完成一些分发工作可以为您提供更多线路，因此比任何协议(protocol)更改都可以使您的速度成倍增加。TCP本质上是具有可靠性层的UDP-正是您所拥有的。然而，TCP是在硬件中

有没有一种方法可以使用java.net.*中的JavaTCP/IP库进行可靠的通信(发送方获知它发送的消息已被接收方接收)？我知道TCP相对于UDP的优势之一是它的可靠性。然而，我无法在下面的实验中得到这种保证:我创建了两个类:1)echoserver=>总是发回它接收到的数据。2)client=>定期向回显服务器发送“Helloworld”消息。它们在不同的计算机上运行(并且运行良好)。在执行过程中，我断开了网络连接(拔下了LAN电缆)。断开连接后，服务器仍在等待数据，直到几秒钟过去(最终引发异常)。同样，客户端也一直发送数据，直到几秒钟过去(引发异常)。问题是，objectOutp

很难说出这里要问什么。这个问题模棱两可、含糊不清、不完整、过于宽泛或夸夸其谈，无法以目前的形式得到合理的回答。如需帮助澄清此问题以便重新打开，visitthehelpcenter.关闭10年前。作为个人项目的一部分，我正在制作一个可靠的应用程序级协议(protocol)(封装在UDP中)。为了实现可靠性，我必须跟踪我发送了哪些数据包，以及在另一端接收了哪些数据包。这是在滑动窗口的帮助下完成的，它还保持了流量控制。除了标准的滑动窗口/流量控制技术之外，是否还有其他方法可以实现可靠性。如果否，是否有人会分享他的经验/设计原理/代码并在这篇文章中进行讨论。如果是，您是否已实现它，或者您是否知

按照目前的情况，这个问题不适合我们的问答形式。我们希望答案得到事实、引用或专业知识的支持，但这个问题可能会引发辩论、争论、投票或扩展讨论。如果您觉得这个问题可以改进并可能重新打开，visitthehelpcenter指导。关闭9年前。虽然TCP是一个提供重传和确认机制的可靠协议(protocol)，但我认为它不是100%可靠的，因为send()的成功返回并不能确保数据已经到达目标端点，只意味着数据是复制到内核缓冲区。有没有什么机制让应用知道数据是否成功到达目的地？一种可能的解决方案是在应用层中建立某种确认机制？

许多游戏开发者选择在应用程序级别中制作UDP可靠。TCP不正是为此而生的吗？我制作了一个API，可以使用UDP和TCP数据包启用客户端-服务器通信。我应该将ReliableUDP添加到列表中吗？为什么？如果我使用TCP会有问题吗？我只是想知道RUDP是否比TCP有任何优势，以便我可以选择是否添加RUDP支持。 最佳答案 简短回答:TCP没有针对延迟进行优化(根本没有)；结果-它有几个属性，这些属性是游戏的延迟killer(尽管它们只有在数据包丢失时才会发挥作用)。特别是，线头阻塞和指数退避对于快节奏游戏来说往往非常烦人。对延迟影响最

我们有一个系统(用C语言构建)可以通过UDP进行通信。最近我们发现有必要保证数据包的传递。我的问题是:要确保使用ack数据包进行交付，对基于UDP的系统的最少添加是什么？此外，理想情况下无需操作数据包header。我们对数据包进行应用程序级别的控制，包括序列号和ack/nack标志。我想知道这是否是一个失败的原因，我们尝试做的任何事情基本上都是有缺陷和损坏的TCP版本。基本上，我们是否可以进行最低限度的改进来实现有保证的交付(我们不需要TCP的许多功能，例如拥塞控制等)。谢谢! 最佳答案 TCP交织了3个可能相关的服务(好吧，TCP