Sending large files with Socket.SendPacketsAsync

Question

0.00/5 (No votes)

See more:

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

Posted 19-Mar-14 12:23pm

Yandy Zaldivar

Updated 19-Mar-14 19:46pm

v4

Add a Solution

1 solution

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Sergey Alexandrovich Kryukov · Answer 1 · 2014-03-19T12:46:00

Solution 1

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

Posted 19-Mar-14 12:46pm

Sergey Alexandrovich Kryukov

Updated 19-Mar-14 14:43pm

v2

Comments

Yandy Zaldivar 19-Mar-14 19:52pm

The Socket.SendPacketAsync is the .NET equivalent to the native Windows API function TransmitFile (http://msdn.microsoft.com/en-us/library/windows/desktop/ms740565%28v=vs.85%29.aspx). The TransmitFile function transmits file data over a connected socket handle. This function uses the operating system's cache manager to retrieve the file data, and provides high-performance file data transfer over sockets. I am particularly interested in benefit from this high-performance file data transfer and not in buffering the data myself as you suggest. While the TransmitFile Windows API function allow 64bit offsets, the .NET equivalent is restricted to a 32bit offset. So my question is why is this restriction on .NET?

[no name] 19-Mar-14 20:20pm

It may be worthwhile to edit your question and add this.

Sergey Alexandrovich Kryukov 19-Mar-14 20:46pm

If does not change anything, I think; OP just did not understand the answer; please see my other comment.
—SA

Sergey Alexandrovich Kryukov 19-Mar-14 20:45pm

Who suggested you to buffer your data, ever? You use benefits of near-maximum performance is you transmit file directly using a network stream of TpcListener/TcpClient.
See also my update to the question, after [EDIT].
—SA

Yandy Zaldivar 20-Mar-14 1:56am

Question edited, read after [Edited].

Sergey Alexandrovich Kryukov 20-Mar-14 10:40am

I got it. Thank you for clarification. Now it's pretty clear.
—SA