[Delphi] IPC - afweging te kiezen methode & info

[OZ-Gump]

situatie
We zijn momenteel bezig met de ontwikkeling van een stuk software (in Delphi 7) dat uiteindelijk op nogal wat verschillende plaatsen moet gaan draaien. Citrix, 'normale' netwerken, netwerken met Linux-servers, enzovoorts. Uiteindelijk is het natuurlijk de bedoeling dat het geheel zo onderhoudsvrij mogelijk gaat draaien. Dit heeft er ook mee te maken dat de kans aanwezig is dat de opdrachtgever het in het buitenland gaat neerzetten.
De applicatie wordt straks opgebouwd uit verschillende modules. Er wordt gebruik gemaakt van DLL's en diverse exes. De vraag in dit topic gaat dan ook over communicatie tussen twee applicaties. IPC dus

enne... zelf al iets gedaan?
Nou, ik ben in ieder geval op zoek geweest naar de nodige info over verschillende manieren om tussen apps te communiceren. Zo ben ik uitgekomen op sockets, shared mem en (named) pipes. Daar heb ik ook al het een en ander over gelezen. Ik zal eerst een aantal zaken opnoemen die ik, waarschijnlijk door duidelijke redenen, niet wil gaan gebruiken:

• register
• bestanden
• tabel

Verder heb ik de andere opties eens bekeken en daarbij kom ik tot de volgende ideeën:

sockets
Lijkt me goed werken, maar het heeft een nadeeltje: het werkt via TCP/IP. Mogelijk is dit helemaal geen probleem, maar ik heb laatst een PC in de knoop gezien omdat een programmeur perse een netwerkkaart nodig had in de PC omdat er gebruik werd gemaakt van sockets
Waarschijnlijk heb ik er daardoor een slecht (en misschien verkeerd) beeld van.

(named) pipes
Binnen de Delphi help weinig info over kunnen vinden. Op internet wordt duidelijk dat er veel componenten voor zijn. Third party componenten werk ik liever niet mee, dus dan maar zelf ...
Op de MSDN Library is er een hele berg over (named) pipes te vinden. Helaas is daar, zoals ik het lees, ook te vinden dat pipes niet gebruikt kunnen worden op win9x en ME. En eigenlijk willen we die ook graag ondersteunen. (Dat willen we helemaal niet, maar dat moeten we )

shared mem
Ook hier vond ik een aantal componenten. Verder kan aan mij liggen, maar shared mem klinkt mij niet als ideale oplossing in de oren. Dat zal wel persoonlijk zijn, maar dat gevoel krijg ik erbij.

wat wil je nou eigenlijk?!!?!
Ik zou het tof vinden om eens wat ervaringsdeskundigen hierover te horen. Ik kan me nu wel blind in een oplossing storten, maar dat lijkt me niet de meest ideale aanpak. Vandaar dat ik me een aantal zaken afvraag:

1. Wat zijn jullie ervaringen met de verschillende opties
2. Zijn er eventueel nog andere opties beschikbaar
3. Wat is, gekeken naar de verschillende doel-netwerken, de verstandigste keuze
4. Hebben jullie tips voor info

uiteindelijk
Waarom zou je hier reageren? Eigenlijk heel simpel: om iemand een duwtje de goede richting in te geven. En natuurlijk niet te vergeten: mijn eeuwige* dank.

Dus: mocht je me van info kunnen voorzien, I'm all eyes....

* _{de term "eeuwig" dient hier met een stevige korrel zout geïnterpreteerd te worden}

[curry684]

Je zegt dat je binnen een netwerk opereert van Linux en Windows bakken... gaat het puur over IPC binnen 1 computer en meerdere processen, of wil je ook over het netwerk? En zo ja, wil je alleen naar Windowsbakken of ook naar de *nix-bakken? En belangrijker: blijft dit ook zo in de toekomst?

En wat voor data wil je versturen? Gaat het om triggers/events, data van variabele grootte of wil je gewoon settings en general info delen tussen diverse processen?

[curry684]

OZ-Gump schreef op 31 oktober 2003 @ 17:14:
Op de MSDN Library is er een hele berg over (named) pipes te vinden. Helaas is daar, zoals ik het lees, ook te vinden dat pipes niet gebruikt kunnen worden op win9x en ME. En eigenlijk willen we die ook graag ondersteunen. (Dat willen we helemaal niet, maar dat moeten we )

Dit klopt niet, anonymous pipes werken wel onder 9x, alleen named pipes zijn NT-only.

[OZ-Gump]

background-info
De applicatie gaat op de werkstations draaien, op de server (of die nu Linux of Windows is) komt de database te staan. Standaard gaan we uit van een Oracle database (dat kies je ook niet vrijwillig, maar je krijgt het er blijkbaar bij als je klanten gemeentes zijn.)

De messages zouden dus binnen één Windows-bak gaan draaien tussen diverse onderdelen van de applicatie. Makkelijkste voorbeeld dat ik nu kan geven is een rapporten-app. De rapporten worden aangeroepen binnen de 'hoofd' applicatie. Deze stuurt zaken als (ado) connectionstring, rapportnaam, gebruikersafhankelijke info naar de rapporten app. Deze vraagt eventueel naar criteria voor het rapport en laat het zien (en eventueel afdrukken). Wanneer de gebruiker wil exporteren vraagt rapporten-app de exportlocatie aan de hoofdapp, die dit terug stuurt naar de rapporten-app.

Ik word er zelf een beetje duizelig van als ik het zo uitleg, ik hoop dat je een beetje mijn richting snapt...

Dit klopt niet, anonymous pipes werken wel onder 9x, alleen named pipes zijn NT-only.

Nu je het zegt, zo staat het er eigenlijk ook wel...

[ Voor 8% gewijzigd door OZ-Gump op 31-10-2003 17:26 ]

[curry684]

Zoals ik het nu zie heb je dus een controllerapp die de rest van de applicaties opstart, en daar zijn anonymous pipes nu exact voor uitgevonden

[Verwijderd]

Ik gebruik TssSimpleIPC
Een hele simpele interface.
Je dropt gewoon het object op je form en je kan al berichten tussen de verschillende applicaties sturen, hetzij een String of een binaire stroom.
Alleen moet je zorgen dat de instelling IPCName hetzelfde zijn tussen de applicaties.

IPCName: String
Specifies the name of IPC. Communications will be valid between the components in different process with same name.

En het allerbelangrijkste is dat je de volledige sourcecode ter beschikking hebt en het freeware is
http://www.delphiabc.com/...impleIPC&TorD=1&quick=yes

[Tomatoman]

OZ-Gump schreef op 31 oktober 2003 @ 17:14:
sockets
Lijkt me goed werken, maar het heeft een nadeeltje: het werkt via TCP/IP. Mogelijk is dit helemaal geen probleem, maar ik heb laatst een PC in de knoop gezien omdat een programmeur perse een netwerkkaart nodig had in de PC omdat er gebruik werd gemaakt van sockets
Waarschijnlijk heb ik er daardoor een slecht (en misschien verkeerd) beeld van.

Mocht je een netwerkadapter nodig hebben, dan kun je altijd de - in iedere Windowsversie beschikbare - 'Microsoft Loopback adapter' installeren. Dat is een virtuele netwerkadapter die niets anders doet dan messages naar localhost (127.0.0.1) terug te sturen naar dezelfde pc. Hiermee kun je sockets gebruiken zonder een fysieke netwerkadapter in je pc.

Een mogelijkheid die je nog niet hebt genoemd, zijn memory-mapped files. Daarmee kun je een file object in het geheugen laden waar diverse programma's toegang toe hebben. Je kunt een fysiek bestand op schijf gebruiken voor de memory mapping, maar dat is niet noodzakelijk. In feite zijn memory-mapped files een heel transparante manier om geheugen tussen applicaties te delen.

Programma's kun je ook nog laten communiceren door het versturen van messages. Waarschijnlijk is dit de eenvoudigst te implementeren manier om programma's te laten communiceren, maar ook de manier met de meeste beperkingen. De grootste beperking is dat je altijd beperkt bent tot de grootte van een TMessage record, zodat je bijvoorbeeld moeilijk tekst kunt versturen.

Verder heb je een heel belangrijke manier van communiceren nog niet genoemd waar Delphi in uitblinkt: communicatie met behulp van de DataSnap-componenten. DataSnap abstraheert het gebruikte communicatieprotocol, zodat je je daar veel minder zorgen over hoeft te maken. Je kunt later heel gemakkelijk switchen tussen (D)COM, sockets en een webconnection. Wel moet je je realiseren dat je daarmee een client-server-architectuur introduceert, terwijl je daar misschien niet op zit te wachten.

[LordLarry]

*Windows Messages
Werkt alleen lokaal. Rete snel. Je kan geen grote stukken data doorgeven. Makkelijk te maken en gebruiken.

*Memory Mapped Files
Grote stukken geheugen kunnen gedeelt worden. Je zal zelf moeten regelen dat niet beide processen (threads) tegelijk gaan schrijven en lezen. Windows Only.

* MailSlots
Werkt over elke beschikbaar netwerk protocol. Er zijn Delphi componenten voor te vinden. Je kan broadcasten. Windows only. Werkt mogelijk niet zonder netwerkkaart.

*Pipes
Werkt over elke beschikbaar netwerk protocol. Win95/98 en ME hebben wat beperkingen. Windows Only. Kan ook lokaal gebruikt worden.

*Sockets
Multi Platform. Netwerk. Werkt mogelijk niet zonder netwerkkaart.

*DDE
Werkt lokaal. Windows Only. Voorloper van COM. Oud. Standaard componenten in Delphi.

*COM/DCOM/COM+
Werkt lokaal en over het netwerk. Windows Only. Ook makkelijk te gebruiken vanuit andere programmeertalen dan je eigen. Ontwikkelen kan ook in vele talen.

*Corba
Lijkt op DCOM/COM+. Meerdere platformen.

*SOAP
Idee van Corba/COM, maar dan via XML en meestal HTTP. Niet echt geschikt voor lokaal.

[ Voor 3% gewijzigd door LordLarry op 31-10-2003 19:43 ]

[farlane]

LordLarry schreef op 31 oktober 2003 een overzichtje over wat IPC technieken@ 19:42:

Met Windows Only bedoel je neem ik aan dat het niet cross-platform gebruikt kan worden ?

[LordLarry]

Yep.

[curry684]

LordLarry schreef op 31 oktober 2003 @ 19:42:
*Windows Messages
Werkt alleen lokaal. Rete snel. Je kan geen grote stukken data doorgeven. Makkelijk te maken en gebruiken.

Messaging is hier niet van toepassing denk ik, daar er variabele grootte data aan rapporten gecommuniceerd moet worden, en sommige facturen heb je het gewoon over megabytes, waar messaging niet op ingericht is. Bovendien ben je dan verplicht je IPC-laag met je GUI-laag te verweven (baaaad).

*Memory Mapped Files
Grote stukken geheugen kunnen gedeelt worden. Je zal zelf moeten regelen dat niet beide processen (threads) tegelijk gaan schrijven en lezen. Windows Only.

Fixed-size, valt dus af

* MailSlots
Werkt over elke beschikbaar netwerk protocol. Er zijn Delphi componenten voor te vinden. Je kan broadcasten. Windows only. Werkt mogelijk niet zonder netwerkkaart.

Mailslots werken perfect zonder netwerkkaart, echter zijn per definitie broadcast. Security nul dus.

*Pipes
Werkt over elke beschikbaar netwerk protocol. Win95/98 en ME hebben wat beperkingen. Windows Only. Kan ook lokaal gebruikt worden.

Nee dit klopt dus niet. Win95/98 en ME ondersteunen alleen anonynous pipes, oftewel een linkup tussen 2 gerelateerde processen op dezelfde computer. Ze zijn in tegenstelling tot mailslots niet af te luisteren omdat het een 1-op-1 connectie is. Alle pipes werken 'streaming', oftewel variable length data in, varlength uit. Je moet wel net als TCP je eigen 'messagestructuur' eroverheen definieren dus.

Named pipes zijn secured (vandaar NT-only) objecten in de kernelnamespace met dezelfde functionaliteit als anonymous pipes, maar dan met de mogelijkheid om tussen 2 ongelateerde apps te werken (ze kunnen op naam openen) en met de mogelijkheid om transparant over netwerk te opereren. Pipes zijn lightning fast en verdienen in alle gevallen de voorkeur.

*Sockets
Multi Platform. Netwerk. Werkt mogelijk niet zonder netwerkkaart.

Pas interessant zodra je over internet hangt of naar platformen die niet met Windows-pipes kunnen praten. Localhost TCP is relatief gezien een getikte overhead. Localhost werkt overigens perfect zonder netwerkkaart daar er altijd een fake loopback adapter aanwezig is (ook onder Windows).

*DDE
Werkt lokaal. Windows Only. Voorloper van COM. Oud. Standaard componenten in Delphi.

Deprecated.

*COM/DCOM/COM+
Werkt lokaal en over het netwerk. Windows Only. Ook makkelijk te gebruiken vanuit andere programmeertalen dan je eigen. Ontwikkelen kan ook in vele talen.

Overly complex en irritant te programmeren. Eigenlijk alleen gebruiken als je moet interfacen met andere COM-apps.

*Corba
Lijkt op DCOM/COM+. Meerdere platformen.

Zie COM

*SOAP
Idee van Corba/COM, maar dan via XML en meestal HTTP. Niet echt geschikt voor lokaal.

Inderdaad alleen bedoeld voor als je geen idee hebt wie de ontvanger en zender zijn.

Mijn mening blijft een anonymous pipe: alles klaar met 5 API-calls, simpel, retesnel en betrouwbaar.

[LordLarry]

Als ik het goed lees worden er alleen paramters heen en weer gestuurd. Geen grote stukken data. Bovendien zijn die parameters onderdeel van aan functie die uitgevoerd moet worden door een ander process. Ik lees hier Remote Procedure Calls.

Aangezien het bij COM precies daarom draait zou ik deze nemen. Zoals je zelf al zegt moet je bij Pipes zelf nog je eigen 'messagestructuur' maken, terwijl dat bij COM al niet meer hoeft. Ik ben het ook niet helemaal met je eens dat het in Delphi complex en irritant te programmeren is. Delphi haalt juist veel van de moeilijheid uit het COM programmeren. Ik moet er wel bij zeggen: Als het om zeer beperkt aantal aanroepen gaat en dit niet veel veranderd is COM misschien wat te zwaar, maar daarentegen brengt het ook vele nieuwe mogelijkheden.

[Tomatoman]

Als er alleen een paar parameters heen en weer moeten, ben je met messages goed af. Als je meer wilt dan dat of als je remote wilt werken, lijkt COM me de beste keuze. Zie messages als de lightweight oplossing en COM (en DCOM) als de heavyweight oplossing. Van pipes weet ik niet genoeg om daar wat zinnigs over te zeggen.

[curry684]

Idd maakt Delphi het gebruik van COM wel stukken makkelijker, dat kan het idd wellicht een waarschijnlijkere optie maken. Dus de vraag blijft aan OZ-Gump: definieer eens exact wat je heen en weer moet sturen? Zitten daar complete DB-queries e.d. bij of alleen trapjes? Etc.

[OZ-Gump]

Tof dat er zoveel constructieve opmerkingen dit topic in gegooid worden. Deze discussie (en de info) zorgen er in ieder geval voor dat ik iets meer gevoel krijg bij de verschillende oplossingen.

Om curry684 te antwoorden:
Zoals ik al aangaf sta ik nog voor de keuze op dit moment. Aangezien bijvoorbeeld de rapporten (ik houd mijn voorbeeld even aan) dynamisch geladen moeten kunnen worden vanuit een daartoe bestemde map, denk ik dat ik de controllerapp alleen door wil laten geven welk rapport er aangeroepen wordt en eventueel door wie. Bij nader inzien is de databaselocatie door de rapportenapp uit het register te halen, waardoor ik deze niet hoef mee te sturen. De voor het rapport benodigde query zit in het bestand van het rapport verwerkt, of bevindt zich eventueel in een andere tabel of een tweede bestand. Voor mijn gevoel gaat dus enkel de rapportnaam en de aanroeper ervan naar deze rapportenapp.
De rapportenapp hoeft aan de hoofdapp alleen door te geven wat er gebeurd is en door wie, in verband met logging van acties. Verder geeft hij aan de hoofdapp door wanneer hij klaar is. Niet schokkend veel verkeer daar dus

echter
De rapportenapp is één voorbeeld. We willen straks (aangezien het project nu nog in de startfase is, en er nog het een en ander gemaakt moet worden ) gebruik gaan maken van wellicht nog meer apps en dll's. Aangezien de databaselocatie en dat soort zaken echter allemaal in het register te vinden zijn, denk ik niet dat er volledige connectionstrings meehoeven, of complexe queries verzonden moeten worden. Volgens mij is dat allemaal prima in de aangeroepen app te realiseren.

Ik wil jullie bij deze alvast bedanken voor de nuttige info die ik hier al voorbij heb zien komen enne.... keep 'em commin'

[ Voor 7% gewijzigd door OZ-Gump op 01-11-2003 20:59 ]

[curry684]

Als het puur om events gaat zou ik Windows messages gebruiken, met meer data anonymous pipes, distributed data TCP, met open interfaces (D)COM

[OZ-Gump]

curry684 zijn laatste reply in combinatie met zijn uitspraak

Pipes zijn lightning fast en verdienen in alle gevallen de voorkeur.

zorgt ervoor dat ik maar eens wat meer over pipes ga lezen. Ik heb op MSDN een interessant stukje leesvoer gevonden, over zowel anonymous als named pipes. Dan heeft een eventuele toevallige voorbijganger ook nog iets aan dit topic mocht hij of zij het over een tijdje in de search tegenkomen

[curry684]

Mental note: anonymous pipes zijn eenrichtingsverkeer! Dus als je feedback nodig hebt vanuit de childapp krijg je daar dezelfde keuze.

Als je vanuit de childprocesses alleen simpele completion/shutdown events hebt kun je terugmessagen, anders pak je gewoon 2 anon pipes

[BoomSmurf]

Messages lijkt me hier het beste. Iemand zei hier ook dat je daar geen strings e.d. kon versturen en gelimiteerd was aan de grootte van TMessage (klopt dus gewoon niet -> WM_COPYDATA is speciaal voor dit doel). Verder kun je met 1 event ook de hele zooi afvangen dus die 'verweving' met de GUI valt ook allemaal reuze mee.

[curry684]

Mja ik vind WM_COPYDATA gewoon een lelijk mechanisme, met een hoop inherente nadelen. Op zich is het een hele simpele en efficiente methode, maar ook een die heel makkelijk uitnodigt tot fouten, vereist dat de ontvanger een messageloop bijhoudt (leuk voor services en zo, moet je messagewindows aanmaken), vereist dat er een manier is waarop de zender het messagewindow van de child kan vinden (kip en ei probleem ), en mijn opmerking over het verweven van GUI met datalayer betrof niet de potentiele complexiteit als wel de potentiele constipatie van de messagebus die je hiermee veroorzaakt (je mousemessages e.d. worden niet afgehandeld terwijl je de WM_COPYDATA afhandelt). Dit laatste is wel af te vangen door een messagewindow en -loop in een aparte thread te maken, maja dan schrijf je weer 5 keer zoveel code als voor een willekeurig andere IPC-mechanisme. Tot slot nodigt WM_COPYDATA uit tot het foutief doorsturen van handles e.d. waardoor je de meest wazige securitybugs voor je neus krijgt.

In short: ik vind het geen elegant mechanisme

[BoomSmurf]

Het WM_COPYDATA mechanisme heeft idd wel een aantal nadelen, maar het gaat in dit geval vooral voor parameters, directories, etc, doorsturen. De genoemde problemen zijn vooral van toepassing op grotere hoeveelheden en hogere frequentie van verzonden informatie.

(Verder is een aparte thread met messageloop ook nog geen 10 regels code, dus waarom je je daar zo druk over maakt...)

In short: niet elegant misschien, toch zou ik in dit geval messages verkiezen boven pipes/slots/sockets/(D)COM(+).