简体   繁体   English

为什么TcpClient的此代码在vb.net中有效,而在c#中却无效?

[英]Why does this code for TcpClient work in vb.net, but not c#?

A little experiment here, code that I inherited and plan to refactor, but I'm stumped on one thing. 这里有一个小实验,我继承并计划重构的代码,但是我迷上了一件事。 The one in vb.net works, but the one in c# does not. vb.net的一个有效,但c#中的一个无效。

By the way, BUFFER_SIZE is equal to 2048 , and I know it has several issues, but I can only assume I'm misunderstanding the correlation between Byte constructs with the two languages: 顺便说一句, BUFFER_SIZE等于2048 ,我知道它有几个问题,但是我只能假设我误解了两种语言的Byte构造之间的相关性:

Dim bytesRcvd As Integer = 0
Dim byteSendBuffer As Byte() = New Byte(BUFFER_SIZE - 1) {}
Dim byteReceiveBuffer As Byte() = New Byte(BUFFER_SIZE - 1) {}
Dim receiveMessage As String = Nothing
byteSendBuffer = Encoding.ASCII.GetBytes(sendMessage)
Dim client As System.Net.Sockets.TcpClient = Nothing
Dim netStream As System.Net.Sockets.NetworkStream = Nothing

client = New System.Net.Sockets.TcpClient("localhost", 9060)

netStream = client.GetStream()

netStream.Write(byteSendBuffer, 0, byteSendBuffer.Length)
bytesRcvd = netStream.Read(byteReceiveBuffer, 0, BUFFER_SIZE)
receiveMessage = Encoding.ASCII.GetString(byteReceiveBuffer, 0, bytesRcvd)
netStream.Close()
client.Close()

C#: C#:

int bytesRcvd = 0;
var byteSendBuffer = new Byte[BUFFER_SIZE - 1];
var byteReceiveBuffer = new Byte[BUFFER_SIZE - 1];
string receiveMessage = null;
byteSendBuffer = Encoding.ASCII.GetBytes(sendMessage);
System.Net.Sockets.TcpClient client = null;
System.Net.Sockets.NetworkStream netStream = null;
client = new System.Net.Sockets.TcpClient("localhost", 9060);

netStream = client.GetStream();

netStream.Write(byteSendBuffer, 0, byteSendBuffer.Length);
bytesRcvd = netStream.Read(byteReceiveBuffer, 0, BUFFER_SIZE);

receiveMessage = Encoding.ASCII.GetString(byteReceiveBuffer, 0, bytesRcvd);
netStream.Close();
client.Close();

The error received is: 收到的错误是:

Specified argument was out of the range of valid values. 指定的参数超出有效值范围。

This occurs on netStream.read 这发生在netStream.read

Ah yes, so Byte is handled differently.. Focusing on the c# version, changing: 是的,所以Byte的处理方式有所不同。.着重于c#版本,更改为:

var byteSendBuffer = new Byte[BUFFER_SIZE - 1];
var byteReceiveBuffer = new Byte[BUFFER_SIZE - 1];

To this: 对此:

var byteSendBuffer = new Byte[BUFFER_SIZE];
var byteReceiveBuffer = new Byte[BUFFER_SIZE];

No error, but netStream.read hangs indefinitely, so apparently not getting any data back, right? 没有错误,但是netStream.read无限期挂起,因此显然没有获取任何数据,对吗?

I tried wrapping it all with: 我尝试用以下方法包装所有内容:

if(netStream.CanRead()) { ... }

Didn't work, still hangs. 没有工作,仍然挂起。

Can you spot a reason? 你能找到原因吗? Again, yes I'm aware that this is ugly. 同样,是的,我知道这很丑。 I'll get to that. 我会解决的。

Update 更新资料

This is absolutely frustrating. 这绝对令人沮丧。 I've tried numerous examples of suggested configurations for this. 我已经尝试了许多建议的配置示例。 In the new c# (or was) solution, I added a vb project just for TcpClient commands. 在新的c# (或以前)解决方案中,我添加了一个仅用于TcpClient命令的vb项目。 No matter what else I do, it hangs indefinitely on read , but works with vb . 不管还有什么我做什么,无限期地挂在read ,但作品vb

Final Update 最终更新

Well, all of this hassle and helpful advice, and it turns this was one of those huge major coincidences dealing with small details, as in the listening service on the other end that I didn't have access to. 好吧,所有这些麻烦和有用的建议,转而这是处理小细节的巨大重大巧合之一,就像在我无法访问的另一端的收听服务中一样。 The procedure to return the messages to be sent to the listener was returning incorrect messages, and the listener was not responding with data, and it just timed out. 返回要发送给侦听器的消息的过程返回了不正确的消息,并且侦听器未使用数据进行响应,并且超时了。 Such a tiny detail, (like a few characters) that it was hard to spot. 如此微小的细节(如几个字符)很难被发现。

Try this 尝试这个

 bytesRcvd = netStream.Read(byteReceiveBuffer, 0,
 byteReceiveBuffer.Length);

Instead of 代替

bytesRcvd = netStream.Read(byteReceiveBuffer, 0,
     BUFFER_SIZE );

your byteReceiveBuffer length is is 2047 and BUFFER_SIZE is 2048 您的byteReceiveBuffer长度为2047,BUFFER_SIZE为2048

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM