[C#] Gebruik van pipes voor communicatie tussen 2 exec

[JvdS]

Voor communicatie tussen 2 verschillende .NET projecten (executables) maak ik gebruik van named pipes:

code:

new NamedPipeServerStream(PipeName,
                       PipeDirection.InOut,
                       1,
                       PipeTransmissionMode.Message,
                       PipeOptions.Asynchronous,
                       BUFFER_SIZE,
                       BUFFER_SIZE);

Als ik deze manier test in een project met aanroep naar de server en client op de volgende manier gaat het goed:

code:

Server = new NamedPipeServer("pipename");
            Server.OnReceivedMessage += new EventHandler<ReceivedMessageEventArgs>(Server_OnReceivedMessage);
            new Thread(new ThreadStart(Server.Start)).Start();

            NamedPipeClient Client = new NamedPipeClient("pipename");
            Client.OnReceivedMessage += new EventHandler<ReceivedMessageEventArgs>(Client_OnReceivedMessage);
            Client.Start();
            Client.Write("Test");

Het gekke is, dat op het moment dat ik deze twee objecten gebruik in twee verschillende projecten, dat er dan een exceptie optreedt in de pipe: Pipe is broken.
Dit gebeurt op het moment dat de server iets terug stuurt naar de client. Het bericht dat de client heeft gestuurd komt wel aan bij de server.

Nu begin ik me sterk af te vragen of het gebruik van named pipes anders werkt in het geval van verschillende processen. Kan iemand met ervaring hiermee me uit de brand helpen?

[pedorus]

Klinkt alsof bijvoorbeeld de client de pipe al heeft afgesloten of is gecrashed. Hoe dat komt geen idee, ik denk dat we de relevante code niet hebben (NamedPipeServer/Client is een eigen implementatie).

In pedorus in "\[c#]data inbrengen in draaiend programma" staat een wel werkend voorbeeld, hoewel dat maar 1 richting op gaat is het vrij eenvoudig om iets terug te sturen. Het zou niet uit moeten maken dat het om verschillende processen gaat, als het wel uitmaakt doe je waarschijnlijks iets geks met synchronisatie (bijvoorbeeld pipe ophouden zolang totale programma draait, geen using gebruiken).

[D-Raven]

Je kunt ook via WCF met named pipes communiceren. Neemt een hoop van de sores uit handen. Maar het is maar net wat je handig vind.

[JvdS]

Het bleek juist te ontstaan doordat de server de pipe niet goed disconnecte, waardoor deze "corrupt" open bleef staan nadat de client werd afgesloten. Dit heb ik opgelost door een Pipe.Disconnect extra aan te roepen na de laatste Write in de server.

Toch bedankt Pedorus!
@Deathraven: WCF is beetje overkill voor deze situatie, maar toch bedankt! ;-)

[Sebazzz]

D-Raven schreef op woensdag 28 december 2011 @ 21:14:
Je kunt ook via WCF met named pipes communiceren. Neemt een hoop van de sores uit handen. Maar het is maar net wat je handig vind.

Daarvoor heb je helaas wel admin permissies nodig op Windows Vista en hoger en bovendien is het behoorlijke overkill inderdaad.

[D-Raven]

Sebazzz schreef op donderdag 29 december 2011 @ 12:44:
[...]

Daarvoor heb je helaas wel admin permissies nodig op Windows Vista en hoger en bovendien is het behoorlijke overkill inderdaad.

Incorrect. Zolang client en server in de ingelogde user sessie draaien (security context) dan is het geen probleem. Genoeg over te vinden in de officiele docs hierover. Tevens een linkje naar een SO topic hier

En ja het is inderdaad wellicht een beetje overkill. Maar het is maar net waar je je tijd in wilt steken. Ik ken WCF voor tot achter. Dus als ik zoiets als dit zou doen. Dan zou ik 10 minuten nemen om een wcf service in elkaar te draaien, en vervolgens de juiste binding in te stellen. Klaarrr.
Dan heb ik dus geen zin om uren bezig te zijn om vage bugs op te lossen als waar de TS nu tegenaan loopt. Maargoed, daarom zei ik al. Het is maar net wat je handig vindt.

Daarnaast is het natuurlijk ook wel leuk om zoiets uit te zoeken als je er de tijd voor hebt.

[ Voor 0% gewijzigd door D-Raven op 31-12-2011 19:04 . Reden: taalgebruik ]

[Hydra]

D-Raven schreef op donderdag 29 december 2011 @ 12:56:
Gelul.

Zou het heel veel moeite zijn om als je iemand corrigeert, ongeacht of het correct of niet is, dit iets minder respectloos te doen?

[SlaadjeBla]

D-Raven schreef op donderdag 29 december 2011 @ 12:56:
[...]
En ja het is inderdaad wellicht een beetje overkill.

Wat is de overkill waar je het over hebt? Je gebruikt een library om zaken eenvoudiger voor je te maken. Wat is daar overkill aan?
Zou WCF inefficienter zijn dan wanneer je het geheel zelf doet? En zou dat ook maar iets uitmaken binnen niet-performancekritische applicaties? Ik verwacht eerlijk gezegd van niet, maar ben benieuwd naar je antwoord.

[D-Raven]

Hydra schreef op zaterdag 31 december 2011 @ 10:13:
[...]


Zou het heel veel moeite zijn om als je iemand corrigeert, ongeacht of het correct of niet is, dit iets minder respectloos te doen?

Je hebt gelijk. Aangepast, en excuses

[D-Raven]

SlaadjeBla schreef op zaterdag 31 december 2011 @ 16:46:
[...]


Wat is de overkill waar je het over hebt? Je gebruikt een library om zaken eenvoudiger voor je te maken. Wat is daar overkill aan?
Zou WCF inefficienter zijn dan wanneer je het geheel zelf doet? En zou dat ook maar iets uitmaken binnen niet-performancekritische applicaties? Ik verwacht eerlijk gezegd van niet, maar ben benieuwd naar je antwoord.

Het is een afweging, of je voor iets eenvoudigs een framework in je project wilt betrekken of niet. Op het moment dat je een framework gaat gebruiken introduceer je ook de technische overhead e.d. in je project. Dan heb ik het niet meteen over performance, maar meer over kennis die je moet hebben om met het project te kunnen werken.
Beetje hetzelfde als voor iets simpels bv WebRequest direct te gebruiken ipv een of ander web framework. Ga je iets heel simpels doen, en blijft het daarbij, dan is het wellicht een beetje teveel van t goede om gelijk een framework te gebruiken. Maar aan de andere kant, als dit het begin is van een onderdeel welke alleen maar zal gaan groeien, dan is het misschien juist wel een goed idee.
Maar dit is een inschatting die alleen de ontwikkelaar zelf kan maken. Er is ook niet echt een goede of foute beslissing daarin, bij de sommige dingen is het toch een kwestie van 'only time will tell'. Je kunt tenslotte alleen maar inschattingen maken op basis van de situatie op dat moment.