tcpclient连接速度减慢 [英] Slowdown in tcpclient connections

问题描述

我写了一个客户端/服务器应用程序，我使用TcpServer和TcpClient对象来启用此通信。



服务器端我没问题。似乎当客户端执行请求时，服务器回复得如此之快。但客户端在TcpClient初始化时有一点减速。



如何对所有请求使用单个TcpClient初始化？



谢谢！



我尝试过：



我写了这个方法：

Hi,

I wrote a client/server application, I used TcpServer an TcpClient objects to enable this communications.

Server side I had no problem. It seems that when the client perform a request, the server reply so quickly. But Client side there is a little slowdown at the TcpClient initialization.

How use a single TcpClient initialization for all requests?

Thank you!

What I have tried:

I wrote this method:

TcpClient TcpClient = null;
NetworkStream TcpClientStream = null;
public string SendRequest(string command, out string response)
{
   TcpClient = new TcpClient(TcpAddress, TcpPort);      // [1]
   TcpClientStream = TcpClient.GetStream();             // [2]
   byte[] msg = Encoding.ASCII.GetBytes(command);
   TcpClientStream.Write(msg, 0, msg.Length);
   byte[] result = new byte[0];
   msg = new byte[TcpClient.ReceiveBufferSize];
   int i;
   while ((i = TcpClientStream(Read(msg, 0, msg.Length)) > 0)
   {
      Array.Resize(ref result, result.Length + i);
      Array.Copy(msg, 0, result, result.Length - i, i);
   }
   TcpClientStream.Close(); TcpClientStream = null;     // [3]
   TcpClient.Close(); TcpClient = null;                 // [4]
   return Encoding.ASCII.getString(result);
}

结果：每次初始化TcpClient时（ [1] ）减速约一秒钟。

我试图离开他用TcpClient打开替换该语句：

Result: Every time the TcpClient is initialized ([1]) there is a slowdown of about a second.
I tried to leave the TcpClient open replacing that statement with:

if (TcpClient == null)
   TcpClient = new TcpClient(TcpAddress, TcpPort);

并评论 [4] 语句，但 [2] 会抛出InvalidOperationException（套接字未连接）。

我试图在 [1] 之后检查它是否没有连接：

and commenting the [4] statement, but the [2] throws an InvalidOperationException (socket not connected).
I tried to check if it was not connected just after [1]:

if (!TcpClient.Connected)
   TcpClient.Connect(TcpAddress, TcpPort);

TcpClient.Connected为false，但Connect方法抛出SocketException（套接字已连接）

我还试图让TcpClientStream打开评论 [3] 并替换 [2] with：

The TcpClient.Connected is false, but the Connect method throws a SocketException (socket already connected)
I tried also to leave the TcpClientStream open commenting [3] and replacing [2] with:

if (TcpClientStream == null)
   TcpClientStream = TcpClient.GetStream();

这似乎运行得更好。 TcpClientStream.Write正常执行而没有任何减速，但是服务器没有收到消息。

and this seems to run better. The TcpClientStream.Write is executed normally and without any slowdown, but the server doesn't receive the message.

推荐答案

将它放在讨论中可能会更好而不是问答，因为我不认为有一个明确的答案，但可以说很多。



首先，如果第[1]行需要一秒钟来执行，这是在主机名上进行DNS查找并建立TCP连接所需的时间。似乎很长一段时间，但它是可能的。如果是这种情况，那么您可能希望保持连接活动以进行多次使用。



您可能会发现将StreamReader和StreamWriter连接到网络流会让生活变得有效更容易 - 您可以在构造函数上设置编码，这些将为您处理缓冲（避免稍微有点可怕的数组大小调整）。这有点像用这些来读/写控制台。确保在想要发送数据时刷新写入器。



重用连接的问题似乎在协议本身，即你需要一个字符串并将其转换为ASCII编码的字节并将其发送到网络中 - 当你完成时没有明显的分隔符。这意味着服务器并不真正知道何时停止从套接字读取 - 只是因为没有数据并不一定意味着结束。你期望至少有一条新的线路或什么东西来表示传输的结束。



同样在接收端，我相信你只是继续阅读，直到有没有更多的数据 - 读取返回< = 0.这意味着它将继续读取或阻止那里直到连接关闭，所以没有某种划界你不能重复使用连接。



如果你得到小的延迟，它值得读取Nagle算法。



此外，在关闭套接字之前关闭套接字是一种好习惯。这有助于为沟通带来优雅的结束。一般来说，你不需要它，但我没有看到偶然的问题。

It might be better putting this in the discussions rather than Q&A, as I don't think there's a clear answer, but lots which could be said.

Firstly, if line [1] is taking a second to execute, that's how long it takes to do the DNS lookup on the hostname and establish the TCP connection. Seems like a long time, but it is possible. If this is the case then you probably will want to keep the connection alive for multiple uses.

You might find that attaching a StreamReader and StreamWriter to the network stream makes life easier - you can set the encoding on the constructors and these will take care of the buffering for you (avoiding the somewhat hideous array resizing). It'll be a bit like reading/writing to the console with those. Make sure you flush the writer when you want to send the data.

The problem with reusing the connection seems to be in the protocol itself, that is you take a string and turn it into ASCII encoded bytes and fire it down the wire - there is no obvious delimiter to say when you are done. This means the server doesn't really know when to stop reading from the socket - just because there is no data there doesn't necessarily mean the end. You'd expect at least a new line or something to signal the end of transmission.

Similarly on the receiving end, I believe you just keep on reading until there is no more data there - Read returns <= 0. This means it will keep on reading or blocking there until the connection is closed, so without some sort of delimitation you cannot reuse the connection.

If you get small delays, its worth reading up on the Nagle Algorithm.

Also, it's good practice to shutdown the socket prior to closing it. This helps bring about a graceful end to the communication. Generally, you don't need it but I have seen occasional problems without it.

[1]：不，我想不是。如果我使用127.0.0.1作为地址，它还需要一秒钟。



对于其他你的积分，我跟着你的消息。但不适用于ASCII编码。我必须遵循不止一条路径，有时我没有收到ASCII字符串。然后服务器写入数据的长度和其余的数据，然后客户端读取数据的长度并等待确切的字节数。



谢谢

[1]: no, i think not. It needs a second also if I use 127.0.0.1 as the address.

For the other your points, I followed your sudgestions. But not for the ASCII encoded. There are more than a single path I have to follow, some times I don't receive a ASCII string. Then the server writes the lenght of the data and the rest of the data, Then the client read the lenght of the data and wait for exactly that number of bytes.

Thank you

这篇关于tcpclient连接速度减慢的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！