c # - Windows Navngivne rør arbejder ikke over netværk?

Indlæg af Hanne Mølgaard Plasc

Problem



Jeg støder på mærkelige problemer med navngivne rør på Windows i C #.


Klient:


    NamedPipeClientStream pipeStream = new NamedPipeClientStream("default-PC","mypipe");

    pipeStream.Connect();
    BinaryWriter sw = new BinaryWriter(pipeStream);
    sw.Write((byte[]) data);


Server:


    NamedPipeServerStream pipeStream = new NamedPipeServerStream("mypipe");
    byte[] dataAll = null;
    pipeStream.WaitForConnection();
    dataAll = new BinaryReader(pipeStream).ReadBytes(1024 * 1000 * 512);


-


Hvis jeg bruger '.' som et servernavn i konstruktøren for NamedPipeClientStream fungerer alt korrekt, dvs. serveren fylder dataAll-objektet.


Nu er den mærkelige ting , hvis jeg på den anden side sætter computerens netværksnavn ('standard-pc') i NamedPipeClientStream som vist i koden ovenfor , så læses ingen data på serveren som ReadBytes i serverkoden returnerer et tomt array.


Det kunne forstå, at jeg kørte serveren og klienten på to forskellige computere, men de kører begge på samme maskine. Den eneste forskel er, om parameternavnet 'Servernavn' i NamedPipeClientStream er '.' eller det egentlige netværksnavn (eller endda lokalhost).


Nogle ideer?

Bedste reference


Jeg tror, ​​at begge '.' og 'localhost' betragtes som særlige navne og må ikke bruge de normale netværksforbindelser, men en loopback af en eller anden slags.


Når du angiver et computernavn, selv din egen computers navn, bruger den standard netværksprotokoller/stak/etc.


Du skal nok åbne en firewall-port. TCP 445. Også som standard tillader Windows alle udgående kommunikation. Du skal kun tilføje en indgående port undtagelse. Din konfiguration kan naturligvis variere.
.NET 3.5 (C #) Navngivet rør over netværk

Andre referencer 1


Så konklusionen er dette:


Hvis parameternavnet Parameter i NamedPipeClientStream er noget andet end '.' så er den underliggende implementering gennem et transportlag, der understøtter maksimalt 64 k i en enkelt skriveoperation. Problemet er, at hvis du skriver mere end 64k, forsvinder dataene bare i stedet for at smide en undtagelse.


Løsningen er at bruge NamedPipeClientStream direkte og skrive dataene i mindre end 64 kb klumper.