关于将 EndPoint 传递给 Socket.ReceiveFrom() 的不确定性
如果我执行以下操作:
byte[] buffer = new byte[1024];
Socket sock = new Socket(AddressFamily.InterNetwork, SocketType.Dgram, ProtocolType.Udp);
IPEndPoint remote = new IPEndPoint(IPAddress.Parse("12.34.56.78"), 1337);
sock.ReceiveFrom(buffer, ref remote);
ReceiveFrom 方法是否仅从正在传递的端点接收数据包?该文档说明如下:
对于无连接协议,ReceiveFrom 将读取第一个 接收到本地网络缓冲区的排队数据报。
这是否意味着传递的 EndPoint 仅用于存储数据包来自的主机的 EndPoint,并且根本不影响 ReceiveFrom 方法的行为?如果是这样,为什么需要将其作为“ref”而不是“out”传递?
If I do something like this:
byte[] buffer = new byte[1024];
Socket sock = new Socket(AddressFamily.InterNetwork, SocketType.Dgram, ProtocolType.Udp);
IPEndPoint remote = new IPEndPoint(IPAddress.Parse("12.34.56.78"), 1337);
sock.ReceiveFrom(buffer, ref remote);
Will the ReceiveFrom method only receive packets from the endpoint that is being passed? The documentation states the following:
With connectionless protocols, ReceiveFrom will read the first
enqueued datagram received into the local network buffer.
Does that mean that the passed EndPoint is only used for storing the EndPoint of the host the packet has come from and does not affect the ReceiveFrom method's behaviour at all? If so, why does it need to be passed as "ref" instead of "out"?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
请注意,
ReceiveFrom
方法是recvfrom WinSock 函数。该函数采用一个指向sockaddr
结构的指针,该结构是可选的,并在调用方分配/释放。考虑到这一点,我有一些理论为什么
EndPoint
作为ref
传递而不是out
:ref
传递。EndPoint
在某些时候被认为是可选参数,但这从未实现(我检查过,它必须是非空的)。Note that
ReceiveFrom
method is a managed wrapper for recvfrom WinSock function. This function takes a pointer tosockaddr
structure that is optional and allocated/deallocated on the caller side.With that in mind I have a few theories why is the
EndPoint
passed asref
and notout
:EndPoint
is allocated by the caller and therefore passed byref
.EndPoint
was at some point considered to be an optional parameter, but this was never implemented (I checked, it must be non-null).EndPoint
parameter. Maybe even future protocols :-)