We are exploring various alternatives for transferring binary files across
our Intranet. We have a software application which stores files in a central
filesystem repository. Because of the nature of the application, performance
is a primary factor.

Option 1:
----------
So far, the quickest file transfer performance is through the use of a
Windows Folder Share. However, that's not very secure. If we must expose
read/write access to a Windows Folder then that means that anyone can make
an end-run around our software and access that folder directly.

Option 2:
----------
We explored native Web Services but abandoned that since native Web Services
require conversion to Base-64 encoding (and then subsequent decoding at the
workstation) in order to transfer binary data across the wire.

Option 3:
----------
We've explored using Web Service Enhancements and DIME to transfer binary
attachments. This solution is MUCH better than native web services, but
still lags a bit behind Option 1 in terns of performance.

Option 4?
----------
Is there any way to use Remoting to accomplish binary file transfer? I'm
asuming that a Remoting solution would cut IIS/HTTP out of the loop and
deliver binary transfer via TCP, which might yield better performance. Am I
on the right track here?

Thanks for any advice which you can provide. And if I've overlooked any
other alternatives, please let me know.

- Joe Geretz -

Hi,

just wanted to make one remark about option 4. Remoting has no
security.... (requires SLL)

Hope this helps,

Marvin Smit.


On Thu, 8 Sep 2005 18:47:03 -0400, "Joseph Geretz"
<jgeretz (AT) nospam (DOT) com> wrote:

Hi Marvin,

I don't understand what you mean here. The problem with direct file acces
(via folder shares) is that there is no application process on the server
regulating access to the files. Therefore they can be accesed via the client
application, or directly by the user, via the windows shell.

Imposing a Web Service allows us to verify (via our own server process) on
every access, who is making the request, and where the request is emanating
from. Similarly, remoting would allow the same. This is the type of security
we are dealing with.

As far as across-the-wire security, we could use SSL. In this respect,
Remoting would be no different than Web Services. Am I missing something?

Thanks,

- Joe Geretz -

"Marvin Smit" <marvin.smit (AT) gmail (DOT) com> wrote

I might just use tcp sockets as your pretty much dealing a simple
request/reply pair. The request could be an xml doc that you parse and
verify. The reply is the file stream. You might also be able to do a
blended solution. Where WSE handles the request and security, which returns
some one time key. It also starts some tcp listener if not started already.
Then the client sends request (with the key) to the tcp listener and
verifies against a table your WSE service maintains. The key is index into
the dictionary which contains other info such as FileName requested during
WSE auth part. Once the verify is done, the socket part just streams down
the file or closes the socket if verify failed.

--
William Stacey [MVP]

"Joseph Geretz" <jgeretz (AT) nospam (DOT) com> wrote

Hi William,

Thanks for your reply.

This is the part which concerns me. I haven't done a whole lot of socket
programming. I've written socket clients, but never a socket server.

In order to deal with sockets, won't I need some sort of multithreaded
socket listener on the server to fulfill simultaneous requests? This is the
added value that either IIS or COM+ bring to the table and so I'd like to
leverage either of these server-side infrastructures.

On the other hand, how difficult is it to implement what you propose? Do you
have any links to case studies or examples which I could take a look at?

Thanks!

- Joe Geretz -

"William Stacey [MVP]" <staceyw (AT) mvps (DOT) org> wrote

If you want to leverage existing stuff, then WSE and DIME is probably a good
solution. Test it first for speed before you deside if the speed it not
good enouph for you. Unless your sending very large files (>50MB), I don't
think speed will be a big issue. If it is, then you may want to look at
sockets. There are many examples on the web. Just google for .Net sockets.
Their are many books as well. The VS help is pretty good too. I don't have
a specific example handy to ref. I might take another look at DIME.
Cheers.

--
William Stacey [MVP]

Long ago someone posted this same question. TCP/IP and option 4 is the way
to go; you will find it very fast. Anything based on HTTP or web services is
slow; we found them useless for real-time or large amounts of data. TCP/IP
will probably still be slower than folder sharing.

On the client end, use TcpClient and BeginRead on the stream. On the server,
use TcpListener, and create a separate client writing object for each Socket
accepted. The client writer can use BeginWrite. This way you make optimal
use of the built-in thread pooling. For transferring files, little code is
needed.

Here is an example of a simple client/server using TCP/IP:

http://www.vgdotnet.com/articles/real_time_vis.shtml


Regards,
Frank Hileman

check out VG.net: http://www.vgdotnet.com
Animated vector graphics system
Integrated Visual Studio .NET graphics editor

"Joseph Geretz" <jgeretz (AT) nospam (DOT) com> wrote