none
Which port is used by System.IO.FileStream? RRS feed

  • Question

  • if im using System.IO.FileStream to write a file to UNC path, which port will be used for coping?

    MemoryStream source = new MemoryStream();

    var uncfilepath = \\server\folder\filename.txt

    System.IO.FileStream fs = new FileStream(uncfilepath,.......,.......)

    source.CopyTo(fs);

    Tuesday, March 12, 2013 2:06 PM

Answers

  • Have you tried copying the file using Windows Explorer?  .NET uses the exact same Win32 API that Windows Explorer does.  If it is slow in one place then it'll be slow in the other.  Tools like Process Monitor, Task Manager and even PerfMon can help diagnose slow network connections.  In my experience the issue is a routing issue on the network.  You can use TraceRt and ping to see where and how long it is taking to get to the machine.  Often times a bad switch or route can slow things down.

    The reason I'm avoiding the port question is that it is unlikely to be the issue.  Irrelevant you'll see the same behavior whether it is .NET or not.  Under the hood .NET is going to call the same API that Windows Explorer is using.  If one is slow then they both will be.  Literally if you look at the code it is a call to Win32 to write the file.  You haven't provided information on the OS version so the underlying protocol that Win32 will use depends, as referenced in the link.  ReadFile and WriteFile are going to use the same protocol (http://msdn.microsoft.com/en-us/library/windows/desktop/aa365233(v=vs.85).aspx).  In the firewall software it is generally listed as Core Network, Windows Network, Workstation or Server depending upon your firewall.  If the port wasn't open then it would simply fail but then again so would most other network features.  If you really want to eliminate the firewall then temporarily turn it off. 

    Michael Taylor - 3/11/2013
    http://msmvps.com/blogs/p3net

    Wednesday, March 13, 2013 2:24 AM
    Moderator
  • The copy uses a virtual port inside windows that tunnels through the operating system.  It doesn't use a traditional TCP port.

    jdweng

    Wednesday, March 13, 2013 7:00 AM

All replies

  • Under the hood it uses Win32's file operations, in this case most likely ReadFileEx since you're reading a stream.  MSDN has started to document the protocol that will be used based upon the OS you're running on.  Here's the link for ReadFileEx (http://msdn.microsoft.com/en-us/library/windows/desktop/aa365468(v=vs.85).aspx).  Basically if you have Workstation running on the client and Server running on the server then it'll just work.  There is no need to explicitly punch holes through the firewall for the core networking infrastructure as that has already been done at installation time.  Basically if you can copy files from machine A to machine B via Windows Explorer then .NET will work.

    Michael Taylor - 3/12/2013
    http://msmvps.com/blogs/p3net

    Tuesday, March 12, 2013 6:41 PM
    Moderator
  • Thanks

    im reading the stream from memory on source machine and from source machine im writing it to destination machine using FileStream. The code will run on Source Machine. I wanted to know which port will be used on Destination Machine?

    Note that code is able to copy stream to destination machine so im sure whatever the port is, its open. But its taking long time to copy stream from machine A to machine B, so we wanted to check if there is anything that's blocking the port.

    Same code can copy stream from machine A to machine C within expected time limit however its the machine B we are having issues.

    Also, i could not find any port information in the provided link, the ReadFileEx is only used for Reading..while my issue is not related to reading the file
    • Edited by lax4u Tuesday, March 12, 2013 7:36 PM
    Tuesday, March 12, 2013 7:32 PM
  • Have you tried copying the file using Windows Explorer?  .NET uses the exact same Win32 API that Windows Explorer does.  If it is slow in one place then it'll be slow in the other.  Tools like Process Monitor, Task Manager and even PerfMon can help diagnose slow network connections.  In my experience the issue is a routing issue on the network.  You can use TraceRt and ping to see where and how long it is taking to get to the machine.  Often times a bad switch or route can slow things down.

    The reason I'm avoiding the port question is that it is unlikely to be the issue.  Irrelevant you'll see the same behavior whether it is .NET or not.  Under the hood .NET is going to call the same API that Windows Explorer is using.  If one is slow then they both will be.  Literally if you look at the code it is a call to Win32 to write the file.  You haven't provided information on the OS version so the underlying protocol that Win32 will use depends, as referenced in the link.  ReadFile and WriteFile are going to use the same protocol (http://msdn.microsoft.com/en-us/library/windows/desktop/aa365233(v=vs.85).aspx).  In the firewall software it is generally listed as Core Network, Windows Network, Workstation or Server depending upon your firewall.  If the port wasn't open then it would simply fail but then again so would most other network features.  If you really want to eliminate the firewall then temporarily turn it off. 

    Michael Taylor - 3/11/2013
    http://msmvps.com/blogs/p3net

    Wednesday, March 13, 2013 2:24 AM
    Moderator
  • The copy uses a virtual port inside windows that tunnels through the operating system.  It doesn't use a traditional TCP port.

    jdweng

    Wednesday, March 13, 2013 7:00 AM