C++ server C# client protocol.

[epic007]

Ik wil een user interface gaan bouwen in c#. Deze zal met een server moeten gaan communiceren die in c++ is geschreven. De communicatie gaat over het starten en stoppen van processen, configuratie parameters die worden opgestuurd plus status informatie.

Ik zit nu een beetje in dubio welk protocol ik hiervoor ga gebruiken.

1. Eigen binair protocol.
De server stuurt binaire berichten die in de C# app via marshalling worden omgezet.

2. Protocol buffers
Door google ontwikkeld protocol. C# wordt niet officieel ondersteund.

3. Wrapper via COM+ WCF of zoiets.
Geen ervaring mee. Zie op internet wel voorbeelden van c++ clients die met een WCF server communiceren, maar niet andersom.

4. Iets anders?

Ik neig naar optie 1. omdat de server ook al communiceert met een aantal microcontrollers via tcp/ip en daar is al een protocol voor ontwikkeld.
Heeft iemand al eens iets dergelijks gedaan?

[t_captain]

Optie 1: klinkt als high maintenance. Over een paar jaar zit jij misschien ergens anders en dan mag je opvolger zich gaan verdiepen. Proprietary = duur als je kijkt naar TCO.

Optie 3: Dat is vrij logisch. COM+ komt nog uit het tijdperk voor .NET. Deze oplossing dient om ouderwetse clients te integreren in een .NET EAI omgeving. Het zal niet de bedoeling zijn om de server om te butsen naar COM+

Optie 4: Ik zou kiezen voor een oplossing die eenvoudig is qua gebruikte technologie en zoveel mogelijk van standaarden gebruik maakt. Eventueel zet je een nieuwe interface voor de server, zodat je client bijvoorbeeld met JSON over REST interfaces kan communiceren. In een volgende versie van de server implementeer je die REST interface native en faseer je de protocol translation uit.

[evolution536]

Je eigen protocol. Je maakt een struct met de gegevens die je in je pakket hebt, definieert alle mogelijke opties (bijv. OPEN, HANDSHAKE, CLOSE, etc), en je schrijft een classe die zorgt voor het omzetten van de informatie in een string/byte array, en van string naar struct. In c# heb je de klasse Socket, voer hier alleen de pakketgegevens in en de socket doet onder water de rest voor je. Ik meen dat in C++ hier de winsock2 klasse erg goed voor is.

[Hydra]

t_captain schreef op maandag 25 juni 2012 @ 09:48:
Optie 1: klinkt als high maintenance. Over een paar jaar zit jij misschien ergens anders en dan mag je opvolger zich gaan verdiepen. Proprietary = duur als je kijkt naar TCO.

Mee eens.

Optie 4: Ik zou kiezen voor een oplossing die eenvoudig is qua gebruikte technologie en zoveel mogelijk van standaarden gebruik maakt. Eventueel zet je een nieuwe interface voor de server, zodat je client bijvoorbeeld met JSON over REST interfaces kan communiceren. In een volgende versie van de server implementeer je die REST interface native en faseer je de protocol translation uit.

Idem. Dan is het ook relatief simpel om later die C++ server uit te faseren indien nodig en er iets anders voor in de plaats te zetten.

evolution536 schreef op maandag 25 juni 2012 @ 09:48:
Je eigen protocol. Je maakt een struct met de gegevens die je in je pakket hebt, definieert alle mogelijke opties (bijv. OPEN, HANDSHAKE, CLOSE, etc), en je schrijft een classe die zorgt voor het omzetten van de informatie in een string/byte array, en van string naar struct. In c# heb je de klasse Socket, voer hier alleen de pakketgegevens in en de socket doet onder water de rest voor je. Ik meen dat in C++ hier de winsock2 klasse erg goed voor is.

Zijn vraag is niet hoe hij het moet doen maar of hij het moet doen, en daar geef je geen voor- of tegenargumenten voor.

[ Voor 29% gewijzigd door Hydra op 25-06-2012 09:52 ]

[TheNephilim]

JSON lijk mij inderdaad een goede oplossing, lekker universeel.

[epic007]

Dank, inderdaad REST via JSON is wel mooi.. dan zou de UI eventueel zelfs in een browser kunnen draaien.

Ik maak toevallig al gebruik van de open source Poco libraries en ik zie dat ze ook een commerciele remoting library hebben met JSON ondersteuning. http://www.appinf.com/docs/poco/

Vraag is of de server hierdoor niet veel te complex wordt. Het betreft een industriele applicatie waar de machines voornamelijk autonoom hun werk doen. de UI is dus niet het meest belangrijke onderdeel.

[H!GHGuY]

Ik was enkele jaren terug begonnen aan de 4de versie van mijn applicatie. Deze was ik toen ook in .NET aan het bouwen en ik gebruikte de standaard .NET Remoting om alles af te handelen.
Ik had encryptie en authenticatie lagen toegevoegd zodat ik secure over het internet kon werken.

.NET Remoting is nu echter vervangen door WCF, dus dat lijkt me zeker een valabele kandidaat.

offtopic:
De 4de versie was usable maar nog niet af. Ik had initieel plannen om niet meer onder GPL te werken, maar om het voor een kleine prijs beschikbaar te stellen. De tijd heeft anders uitgewezen en ik heb uiteindelijk de source toch GPL gemaakt en doorgegeven. Er is echter nog niemand actief op beginnen developen.

[yade]

Je zou Redis kunnen overwegen. http://www.redis.io/ Je server zou daar de statistieken bij kunnen houden en de opdrachten zou je met PUBLISH kunnen sturen. Het voordeel van deze aanpak is is dat er vele clients in vele talen beschikbaar zijn, en het nadeel kan zijn dat er een extra component beheert moet worden.

Je zou ook een SOAP server in C++ in kunnen bouwen. Vanuit .NET is hier dan prima mee te communiceren , met bijv. WCF.

Een eigen protocol kan natuurlijk ook, maar dat zou mijn laatste keuze zijn.

Kortom, er zijn een hoop verschillende oplossingen voor het probleem, en het is maar net waar je je het prettigst bij voelt.

[farlane]

Optie 1 ( Als het voldoet voor jouw toepassing ) omdat het al gebruikt wordt door de server die op die manier niet nog een extra protocol hoeft te ondersteunen.

[__fred__]

http://code.google.com/p/protobuf-net/

Die is er ook. Anyway, er zijn meerdere wegen die naar Rome leiden. Ik zou stilstaan bij de requirements die je stelt aan de communicatie, zoals bijvoorbeeld:

• Is het nodig dat ook andere code, niet door jezelf ontwikkeld, communiceert met de server? In dat geval is het wellicht handiger om iets te nemen dat is gebaseerd op open high level standaarden zoals XML of JSON.
• Moet de implementatie klein en eenvoudig blijven? Dan is een meer low level (evt. binair) protocol logischer. Een complete web stack + JSON serializer is wellicht wat teveel van het goede in je c++ service.
• Mag er managed code in de c++ applicatie terecht komen? WCF is erg leuk, maar je c++ server moet wel managed code ondersteunen, of je haalt je alsnog allerlei handmatige en interoperabiliteitszaken op de hals, als je aan de ene kant puur c++ (of evt. COM) gaat doen, en aan de andere kant WCF gebruikt. De .NET runtime, garbage collection, alles krijg je cadeau zodra je managed gaat.
• Wat zijn bandbreedte en/of latencyrequirements. XML is bijvoorbeeld een behoorlijke bandbreedtevreter en wellicht minder geschikt.
• Onderhoudbaarheid: Als je elke week 20 nieuwe functies in je API moet aanbieden, is een standaard protocol wellicht aardig, maar als de API min of meer vast staat, een handvol functies betreft, en zelden tot nooit meer wijzigt, waarom dan geen superefficient, op de situatie toegespitst, binair protocol.

Zonder de requirements denk ik dat iedereen zijn favoriete remoting technologie gaat roepen.

[epic007]

De requirements zijn op dit moment nog niet geheel duidelijk.
Het kan zo zijn dat de UI erg simpel blijft, bijvoorbeeld alleen een start/stop knop o.i.d. maar het kan zomaar zijn dat de gebruiker van alles moet kunnen instellen en allerlei statistieken moet kunnen weergeven.

Ik zit nu ook aan een andere weg te denken, ik wrap het c++ gedeelte in een .net wrapper en gebruik deze in een dedicated server voor de UI (WCF of iets anders). De c++ server voor de microcontrollers blijft dan hetzelfde.

http://msdn.microsoft.com...ry/ms235281(v=vs.80).aspx

[farlane]

Wat levert die extra laag met mogelijke bugs op?