IPC tussen Delphi Win32 applicatie en te bouwen .NET app

[ThaStealth]

Hieronder volgt een lange uitleg van een probleemstelling, naar onderen scrollen voor de samenvatting:

Op het werk hebben wij een server staan die socketverbindingen met data verwerkt (in de regio 0-x0.000) inclusief database verwerking. Deze server is in Delphi geschreven als Win32 applicatie. Om het verwerken van de data een beetje in de gaten te houden heb ik snel-snel een .NET monitoring tool geschreven wat via een socket verbinding maakt met de server en een paar requests doet. Deze requests presenteer ik een een paar listviews/grafiekjes, en ja zelfs een paar progressbars, en het is ook mogelijk om een paar instellingen te wijzigen van de verbindingen.

Natuurlijk heeft op een zeker moment het management team deze app gezien en willen ze voor een select aantal medewerkers ook deze applicatie kunnen gebruiken om ook instellingen te wijzigen, aan mij de opdracht om de geschreven applicatie hiervoor geschikt te maken.

Natuurlijk is het met de architectuur in de huidige opzet geen doen om dit mogelijk te maken, zowel vanwege serverload (ik zal de server met taken op die hiervan gescheiden zouden moeten zijn) Als vanwege veiligheidsrisico's (authenticatiesysteem zit er op het moment halfbakken in, maar voor meerdere gebruikers is het geen goede oplossing).

Om het toch mogelijk te maken heb ik een ontwerp gemaakt waarbij er naast de server een stand-alone monitoring server zit die de andere server in de gaten houdt, en statistieken verzamelt. Met behulp van een andere communicatie manier (wss soap oid) wil ik met de reeds bestaande monitor app de data ophalen.

Hoe kan ik beste met behulp van .NET communiceren met de Delphi server? Het liefste werk ik niet via sockets, Ik heb op internet al verschillende mogelijkheden gezien met bijv named pipes, maar ik vraag me af wat de meest handige manier is.

-Samenvatting-
Hoe laat ik een .NET applicatie communiceren met een Delphi server applicatie (staan op dezelfde machine). Het liefste niet met sockets

[ZaZ]

Tja, kijk op MSDN en je ziet wat er allemaal mogelijk is.
Wil je brute performance ga je naar anonymouse pipes, alhoewel ik niet weet in hoeverre dat nog geldt met .NET erbij. Named pipes, sockets, mailslots etc. Je hebt ze vast allemaal langs zien komen.
Kijk wat ze allemaal kunnen en alleen daarmee kan jij de beslissing maken wat het beste is voor de app.

Zelf grijp ik altijd naar of anonymouse pipes of mailslots. Puur afhankelijk van platform en omdat ik daar mijn eigen libs voor heb geschreven die ik al jaren gebruik. Maar daar hadden net zo goed named pipes tussen kunnen zitten denk ik.
Alleen sockets ben ik niet zo'n fan van.

[.oisyn]

ZaZ schreef op donderdag 03 juni 2010 @ 01:20:
Wil je brute performance ga je naar anonymouse pipes

Mwoa. Als je brute performance wilt moet je voor memory mapped files gaan (@ TS: let niet op die naam, het betekent niet dat er een fysieke file op disk ten grondslag aan hoeft te liggen - feitelijk komt het erop neer dat je een chunk fysiek geheugen in het address space van beide processen mapt), al impliceert dat wel dat je wat low-level zaken zoals synchronisatie (beide processen kunnen immers direct bij het geheugen) zelf moet verzorgen. Plus het feit dat het dan natuurlijk wel zo moet zijn dat beide applicaties op dezelfde machine draaien, wat bij de andere voorgestelde suggesties niet het geval hoeft te zijn. Daarnaast lijkt het me wat overkill voor wat de TS wil. Desalniettemin: memory mapped files <=> brute performance

[ Voor 19% gewijzigd door .oisyn op 03-06-2010 01:53 ]

[ThaStealth]

Brute performance hoeft niet perse,

Zoals eerder aangegeven is het slechts een statistiek-verzamel programma, die max 10 keer per seconde de status (aantal verbindingen, db transacties) afvraagt, via TCP sockets gaat dit zeer goed op het moment (kan zelfs nog trager). Ik wil een eenvoudige manier om te communiceren tussen de applicaties, waar ik niet een compleet transfer protcol hoef op te stellen

[jmzeeman]

Afhankelijk van de grootte van de berichten zijn mailslots dan een goede optie omdat ze erg simpel werken. Het enige nadeel is dat er hiervoor geen direct support in .NET zit. Je zal dan dus in je .NET applicatie de Windows API calls direct moeten importeren en aanroepen maar aangezien dit maar drie erg simpele functies zijn zou dat geen punt moeten zijn.
Het mooie van mailslots is dat ze message based zijn en dat je dus niet zelf hoeft uit te zoeken wanneer je een compleet bericht binnen hebt.

Ik wil een eenvoudige manier om te communiceren tussen de applicaties, waar ik niet een compleet transfer protcol hoef op te stellen.

Een protocol hoeft natuurlijk niet ingewikkeld te zijn, zelfs bij het meest simpele IPC systeem zal je moeten defineren hoe de data heen en weer gaat dit kan je zo simpel of ingeikkeld maken als je zelf wil. Sockets op zich bepalen niet hoe ingewikkeld het wordt, een UDP socket zal net zo simpel werken als een mailslot.

[ Voor 45% gewijzigd door jmzeeman op 03-06-2010 11:01 ]

[ThaStealth]

De voorbeelden van mailslots en named pipes hebben net zoals sockets het nadeel dat ik er alleen bytes overheen kan sturen, het liefste zou ik net zoals bijv soap complete objecten willen oversturen.

[Laurens-R]

Tja dan moet je een lokale SOAP service implementeren. Je hebt ook simpelweg te maken met het feit dat je tussen twee verschillen platforms/frameworks wil communiceren (delphi -> .net) dus hebt een aantal luxes gewoon niet. (Zoals bijvoorbeeld (de)serialization van objects)

Je kan een XML string ook simpelweg converteren naar een bytereeks, deze toch overpompen via een named pipe en weer terugconverteren naar een string in .Net. Wellicht dat je rekening moet houden met unicode e.d. maar dat is op zich goed te doen.

[ Voor 6% gewijzigd door Laurens-R op 03-06-2010 11:39 ]

[ThaStealth]

Is communicatie met comobjecten een mogelijkheid? Ik heb hier diverse dingen over gelezen, maar ik weet niet zo heel veel over de mogelijkheden.

[RobIII]

ThaStealth schreef op donderdag 03 juni 2010 @ 16:48:
Is communicatie met comobjecten een mogelijkheid? Ik heb hier diverse dingen over gelezen, maar ik weet niet zo heel veel over de mogelijkheden.

Alles is een mogelijkheid; als je er maar genoeg ontwikkeltijd in stopt. Het kan zelfs via het clipboard Of het een handige/gunstige/slimme keuze is om comobjecten te gaan gebruiken is een tweede...

[Verwijderd]

Ik ben vorig jaar tegen precies dezelfde uitdaging aangelopen. De tijdwaarneming van het langebaanschaatsen is een legacy systeem ontwikkeld in Delphi 2006. Het nieuwe communicatieplatform voor alle applicaties is op basis van .NET dus moest er een soortgelijke koppeling komen.

De server biedt alleen WCF services aan. Deze zijn backward compatible met SOAP, dus dat was een optie. Een andere optie was een .NET assembly als COM object laden in de Delphi applicatie. We zijn voor de laatste optie gegaan: SOAP is erg traag in Delphi en te beperkt; we wilden een net.tcp binding gebruiken met callback.

De COM interfaces worden gewrapt door standaard Delphi classes, waardoor het voor de ontwikkelaar van de tijdwaarneming een heel natuurlijk en object geörienteerd systeem is. De callbacks worden omgezet in normale events. Dat was het meest lastige. Aan de serverkant kunnen we alle voordelen van WCF benutten, omdat er een .NET assembly client side zit.

Het is allemaal nog snel ook. Simpele berichten komen binnen 1 ~ 3 ms aan lokaal. SOAP was een stuk trager en niet acceptabel voor presentatie van doorkomsten e.d.

[ Voor 3% gewijzigd door Verwijderd op 03-06-2010 17:17 ]

[ThaStealth]

Ik wil het juist andersom, met behulp van mijn te bouwen .NET app tegen de Win32 app praten, dus de Win32 word de server en de .NET app de client

[Verwijderd]

Dat maakt de techniek niet anders. In plaats van een WCF client kun je dan een WCF service bouwen in die .NET assembly die je via COM aanspreekt in je Win32 server. Toch? Beetje creativiteit jongen