VB6: NetDDE communicatie

[anoniem]

Heeft er iemand ervaring met het DDE-en tussen 2 computers (NDDE)? gewoon DDE-en tussen 2 applicaties op 1 pc gaat simpel. Maar over het netwerk lukt wat minder. Ik heb voorbeelden van internet geprobeerd, shares aangemaakt (NetShare.exe), maar iets klopt er niet denk ik. Ik krijg een melding dat er geen "foreign share applications" gevonden kunnen worden. In een ander voorbeeld wordt de DLL-functie NDdeShareAdd niet gevonden in NetDDe.dll. Kortom het lukt niet. Is er iemand die een werkend voorbeeld heeft? Bedankt, Rob

[anoniem]

Waarom NetDDE? Er zijn diverse andere technieken om met een andere computer te communiceren. DCOM/COM+ bijvoorbeeld. TCP/IP is een ander, primitiever middel. Maar ook een Named Pipe is een goede optie. DDE en NetDDE is een verouderde techniek die al nauwelijks meer ondersteund wordt. Kortom, waarom wil je NetDDE gebruiken?

[anoniem]

OK ALEX (of iemand anders). Ik moet lange strings doorgeven van een willekeurig werkstation naar een applicatie op de server. Wat kan ik hier dan het beste (makkelijkste) toepassen? Ik heb al zitten experimenteren met de winsock-control, maar die is onbetrouwbaar in het sluiten van (veel kortstondige) verbindingen. Wel makkelijk in te stellen, maar voor mijn toepassing te onbetrouwbaar. Andere suggesties voor mijn communicatie-functie? Bedankt, Rob

[anoniem]

Een named pipe zou in dit geval wel een goede oplossing zijn, zeker als beide machines Windows NT of 2000 draaien. Helaas werken named pipes niet op een 95/98/ME server-machine. Echter, ik ga er van uit dat je geen 95/98/ME voor de server gebruikt. Hoe het werkt? Simpel. Het geheel bestaat uit maar enkele API calls. Ik zou wel een sample hier kunnen plaatsen uit een van mijn projecten maar daar wordt mijn baas niet blij van. Maar als je gaat zoeken naar ConnectNamedPipe, GetNamedPipeHandleState, TransactNamedPipe, en DisconnectNamedPipe dan kom je al een aardig eind. Voor de client heb je in principe aan CreateFile, SetNamedPipeHandleState, CloseHandle, ReadFile en WriteFile voldoende. Wat ik zelf heb gedaan, btw, is dat ik op de server een extra thread laat lopen die gewoon wacht tot er iets binnen komt over de named pipe. Zo ja, dan is het gewoon een kwestie van lezen, verwerken en een reactie terugsturen. Het nadeel echter is dus dat je continu een applicatie moet laten draaien (b.v. een system service) die de gehele tijd de named pipe uitleest. Maar het voordeel is de name van de pipe die eenvoudig te onthouden is: \\<Servername>\pipe\<Name> waarbij <Servername> de naam van de computer is en <Name> een naam die je zelf mag bepalen. De tweede methode, die zeker handig is als je W2000 gebruikt, is door COM+ of MTS te gebruiken. Op de server maak je daarvoor een ActiveX library aan. Deze dient een MTS object te bevatten. (Of COM+ onder Delphi 6.) Dit object bevat enkele methodes die je zelf mag bepalen. Vervolgens installeer je dit MTS object op de server. Ga daarna via "Start/Settings/Control panel/Administrative tools/Component services" naar de MTS/COM+ omgeving en zoek je object op in deze lijst. Rechtermuisklik erop en exporteer het object als een "Application proxy" naar een *.msi bestand. Op de client machines installeer je vervolgens dit MSI pakketje (want het is een standaard Windows Installer bestand) en daar gebruik je het object alsof het een lokaal COM object is. Dit geeft je erg veel flexibiliteit maar heeft als enige nadeel dat je dus op iedere client een proxy voor het server-object moet installeren. Je kunt ook DCOM overwegen. Dan maak je een gewoon COM object aan in plaats van COM+ en deze gebruik je dus als een remote object. (JouwObject := CoJouwObject.CreateRemote('Servername'); bijvoorbeeld.) DCOM en COM+ hebben als voordeel boven named pipes dat je niet continu je eigen 'listener' server moet draaien om te reageren op berichten over het netwerk. Dit regelt Windows dus voor je. Named pipes daarentegen zijn een stuk sneller dan DCOM/COM+ oplossingen omdat het object niet steeds opgestart en afgesloten hoeft te worden. Al deze technieken zijn redelijk goed gedocumenteerd en er is veel informatie over te vinden op het web. Echter, zoals zo veel van deze communicatie-technieken vereizen ze enige ervaring voordat je ze echt goed kunt gebruiken. Qua eenvoud is COM+ nog het meest eenvoudig om te gebruiken, gevolgd door DCOM en daarna named pipes. Echter, in gebruik zijn named pipes weer eenvoudiger. Ten minste, da's mijn persoonlijke ervaring.[/quote]