使用TcpClient进行通讯的更快方法?

问题描述

| 我正在用C#编写客户端/服务器应用程序,并且进展顺利。目前,一切正常,并且功能十分强大。我的问题是通过连接发送数据包时遇到一些延迟。 在客户端,我正在这样做:
NetworkStream ns = tcpClient.GetStream();

// Send packet

byte[] sizePacket = BitConverter.GetBytes(request.Length);
byte[] requestWithHeader = new byte[sizePacket.Length + request.Length];
sizePacket.CopyTo(requestWithHeader,0);
request.CopyTo(requestWithHeader,sizePacket.Length);

ns.Write(requestWithHeader,requestWithHeader.Length);

// Receive response

ns.Read(sizePacket,sizePacket.Length);
int responseLength = BitConverter.ToInt32(sizePacket,0);
byte[] response = new byte[responseLength];

int bytesReceived = 0;
while (bytesReceived < responseLength)
{
  int bytesRead = ns.Read(response,bytesReceived,responseLength - bytesReceived);
  bytesReceived += bytesRead;
}
(留下一些异常捕获等)服务器执行相反的操作,即它在NetworkStream.Read()上阻塞,直到它拥有整个请求,然后处理它并使用Write()发送响应。 Write()/ Read()的原始速度不是问题(即,发送大数据包的速度很快),但是在不关闭连接的情况下接连发送几个小数据包可能会非常慢(延迟50-100)女士)。奇怪的是,这些延迟在典型的ping时间<1 ms的LAN连接上显示,但是即使ping时间实际上是相同的,但如果服务器在localhost上运行,则不会发生这些延迟(至少是不应为100毫秒)。如果我重新打开每个数据包上的连接,导致很多握手,那对我来说是有意义的,但我不是。就像服务器进入等待状态使它与客户端不同步一样,然后在重新建立本质上是丢失的连接时会感到迷路。 所以,我做错了吗?有没有办法使TcpServer和TcpClient之间的连接保持同步,以便服务器始终准备好接收数据? (反之亦然:有时处理来自客户端的请求要花几毫秒,然后客户端似乎无法准备好接收来自服务器的响应,直到它在阻塞后有片刻醒来为止在Read()上。)     

解决方法

事实证明,我的服务器和客户端毕竟不是完全对称的。我注意到了,但我认为这根本不重要。显然,这很重要。具体来说,服务器是这样做的:
ns.Write(sizePacket,sizePacket.Length);
ns.Write(response,response.Length);
我将其更改为:
// ... concatenate sizePacket and response into one array,same as client code above
ns.Write(responseWithHeader,responseWithHeader.Length);
现在,延迟已完全消失,或者至少在毫秒内不再可测量。因此,那就像是100倍加速。 \\ o / 这仍然很奇怪,因为它向套接字写入的数据与以前完全相同,因此我猜想套接字在写操作期间会收到一些秘密的元数据,然后以某种方式将其传递给远程套接字,以解释它作为小睡的机会。要么是第一次写入,要么是将套接字置于接收模式,导致套接字在收到任何内容之前被要求再次发送时跳闸。 我想这暗示着您会发现所有示例代码都在其中,它显示了如何以固定大小的块(通常在前面带有单个int的名称来描述要遵循的包的大小)来写入和读取套接字我的第一个版本),却没有提及这样做会带来很大的性能损失。     

相关问答

Selenium Web驱动程序和Java。元素在(x,y)点处不可单击。其...
Python-如何使用点“。” 访问字典成员?
Java 字符串是不可变的。到底是什么意思?
Java中的“ final”关键字如何工作?(我仍然可以修改对象。...
“loop:”在Java代码中。这是什么,为什么要编译?
java.lang.ClassNotFoundException:sun.jdbc.odbc.JdbcOdbc...