使用Socket.SendPacketsAsync发送大文件 [英] Sending large files with Socket.SendPacketsAsync

问题描述

我试图使用System.Net.Socket.SendPacketsAsync方法发送文件但是我在大于2GB的文件上收到错误。然后我尝试指定一个文件偏移但只获得2个额外GB，现在能够发送4GB文件。



原因是系统中的偏移字段。 Net.Socket.SendPacketsElement类是Int32。但是，为了表示文件偏移，通常需要Int64字段。我检查了将此值传递给本机方法的内部结构，并且与Windows套接字API中的接受值相对应，特别是TransmitFile函数，它们是长字段。



因此，显然唯一的限制是在Sy​​stem.Net.Socket.SendPacketsElement类提供的接口中。



此类尝试同时支持缓冲区和文件。考虑到这一点，可能字段大小受到限制，因为32位环境中的字节数组限制为Int32最大大小，但不是杀死功能的理由。添加一个新的构造函数重载并使内部偏移字段成为一个很长的值应该就足够了。



这是出于目的的限制，为什么，或只是一个.NET问题？







我的问题是没有寻找发送的替代方案文件。让我再试一次。



.NET Socket.SendPacketsAsync类似于Windows API函数TransmitFile或TransmitPackets，它在escenes后面使用它来传输文件。但是，虽然TransmitFile / TransmitPackets函数允许使用long（64bits）类型的变量指定文件偏移量，但.NET等效函数仅限于int（32bits）类型的变量。此限制将要在.NET中传输的最大文件大小限制为可以使用Int32（4GB）表示的字节数。所以我的问题是：



为什么.NET Framework使用Int32字段来匹配需要Int64字段的API函数，他们有充分的理由或者是错误？



注意：



- 如果你不熟悉TransmitFile函数，那么TransmitPackets函数， Socket.SendPacketAsync函数，SendPacketsElement类等等，请不要回答这个问题。

- TransmitFile函数



- TransmitPackets功能

- Socket.SendPacketsAsync方法

- Sendpacketse lement class

解决方案

由于各自的协议，所有数据包都有大小限制，因此这不是.NET限制（为什么有人会介绍这样的东西？ ）。您可以使用TCP并链接多个数据包（UDP不保证传递和到达顺序，因此您需要创建自己的TPC机制版本，但为什么？）。更好的是，使用类 System.Net.Sockets.TcpListener / System.Net.Sockets.TcpClient 并开发一些应用程序级（ http://en.wikipedia.org/wiki/Application_layer [ ^ ]）协议，根据您的应用需求。







我还建议尽可能避免任何异步API并使用线程，原因如下：

多线程问题？ !!! [ ^ ]，

TcpListener，TcpClient，在Visual Basic 2005中Ping [ ^ ]，

TCP套接字 - 发送和接收问题 [ ^ ]，

异步等待多个Telnet服务器 [ ^ ]。

-SA

Hi,

I was trying to use the System.Net.Socket.SendPacketsAsync method to send files but I get an error on files larger than 2GB. Then I tried to specify a file offset but only get 2 extra GB, for now being able to send 4GB files.

The reason is the Offset field in the System.Net.Socket.SendPacketsElement class is an Int32. However for representing a file offset it is often necesary an Int64 field. I checked out the internal structures that pass this value to native methods and in correspondency with accepted values from the Windows socket API, specifically the TransmitFile function, they are long fields.

Because of this, apparently the only restriction is in the interface provided by the System.Net.Socket.SendPacketsElement class.

This class tries to support both, buffers and files. Considering this, maybe the field size was restricted because byte arrays on a 32bit environment are limited to an Int32 max size but not a reason to kill functionality. Adding a new constructor overload and making the internal offset field a long value should be enough.

Is this restriction on purpose and why, or just a .NET issue?

[Edited]

My question is not looking for alternatives to sending files. Let me try again.

The .NET Socket.SendPacketsAsync is something like the equivalent to the Windows API functions TransmitFile or TransmitPackets, it uses it behind the escenes to transmit files. However while the TransmitFile/TransmitPackets functions allows to specify file offsets using a variable of type long (64bits) the .NET equivalent is restricted to variables of type int (32bits). This restriction limits the maximum file size to be transmitted in .NET to the number of bytes that can be represented with an Int32 (4GB). So my question is:

Why the .NET Framework uses an Int32 field to match an API function that requires an Int64 field, they have a good reason or it was by mistake?

Notes:

- If you are not familiar with the TransmitFile function, TransmitPackets function, Socket.SendPacketAsync function, SendPacketsElement class and so on, please don't asnwer the question.
- TransmitFile function

- TransmitPackets function
- Socket.SendPacketsAsync method
- Sendpacketselement class

解决方案

All packets have size limitation, due to respective protocols, so this is not a .NET limitation (why would anyone introduce such thing?). You can use TCP and chain several packets (UDP does not guarantee delivery and order of arrival, so you would need to create your own version of TPC mechanisms, but why?). Better yet, use the classes System.Net.Sockets.TcpListener/System.Net.Sockets.TcpClient and develop some application-level (http://en.wikipedia.org/wiki/Application_layer[^]) protocol, according to the needs of your application.

[EDIT]

I would also advise to avoid, if possible, any asynchronous APIs and use threading instead, by a number of reasons:
problem in multithreading ? !!![^],
TcpListener, TcpClient, Ping in Visual Basic 2005[^],
TCP Socket - Send and receive question[^],
Async Await Multiple Telnet Servers[^].

—SA

这篇关于使用Socket.SendPacketsAsync发送大文件的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！