Magic J - So 08.08.10 18:44
Titel: In DLL keine DDE-conversation erzeugbar?

---

Hallo zusammen,

folgendes:
Ich möchte einen Datenaustausch zwischen einer DLL und einem Anwendung(EXE) umsetzen.
Dabei soll die DLL bzw. deren Funktion 'GetExtensionVersion' (über IIS) nur aus dem Browser aufgerufen werden.

Nach langem Suchen nach einem geeigneten Konversations-"Medium" habe ich mich für DDE entschieden, da es mir dafür passend schien...

Habe mich also ersmal eingearbeitet und zum Test einen Vcl-DDE-Client und /-Server zusammengebastelt.
Für DDE hab ich dabei lediglich die Funktionen aus der Unit DDEml.pas verwendet (keine Vcl-Komponenten).
Das funktionieren soweit super:
Ich kann also, über DDE, Daten zwischen den beiden Anwendungen problemlos austauschen.

Nun hab ich die DDE-Methoden des Clients in eine extra Unit gepackt und im Quelltext der DLL eingebunden und dort (identisch wie im Vcl-Client) verwendet.

Doch seltsamerweise ist es dem DLL-Client nun aufeinmal nicht mehr möglich eine 'conversation' zum laufenden Server herzustellen. Ich bekomme con der DDE-Methode 'DdeConnect' eine 0 als conversation-handle zurück und es wird der Fehler 'DMLERR_NO_CONV_ESTABLISHED' geworfen.

Wie kann das sein?
Wenn ich die Funktion der DLL, nicht über den Browser, sondern direkt über eine andere Anwendung aufrufe (und somit den HTTP-Request imitiere) funktioniert alles...am Quellcode selber kanns also net liegen...

Hat hier vllt jemand Erfahrung mit DDE?
Jemand eine Idee woran das liegen könnte?

Danke im vorraus für konstuktive Antworten!

Gruß,

Zeus. - Do 12.08.10 17:37

---

Die Frage ist doch viel eher:
Macht Micro$oft IIS eventuell noch etwas anderes oder gar weniger mit der ISAPI-DLL, als ein "normaler" Host?

Prinzipiell funkioniert der Server ja so, dass er eingehende HTTP-Requests an die entsprechende DLL weiterleitet. Dazu muss er sie natürlich erst einmal laden. Danach wird ganz einfach die von der DLL exportierten Funktion HttpExtensionProc aufgerufen, die dann selbstständig dafür verantwortlich ist, aus dem HTTP-Request etwas "schmackhaftes zu kochen".
Ob der Host nun aber IIS oder "selbstgebastelter Host" heißt, dürfte der DLL eigentlich ziemlich schnuppe sein.

Daraus schließe ich, dass - wenn die DLL die selbe ist - das Problem nur am Host liegen kann.
Daher stellt sich mir die Frage, ob DDE eventuell auf irgendeine Eigenart von IIS "allergisch" reagiert, die da wären:

• Multithreading
  
• evtl. anderer Umgang mit Handles (?)
  
• evtl. selber DDE einsetzend (?)
  

Zeus.

Ps: Nein, wir kennen uns nicht ... :lol:

Magic J - Sa 11.09.10 13:35

---

Tja, ich habe immer noch keine Lösung für das Problem gefunden...

Hat irgendwer hier schonmal selber etwas in der Richtung gemacht?

Irgendwelche Ideen wie man das Problem lösen/umgehen kann?

Oder vielleicht altenative Vorschläge zu Umsetzung einer Server-Client Verbindung ohne Komponenten und WindowHandle ?

Schönen Gruß,
Jonas

Astat - Mo 13.09.10 11:42

---

Magic J hat folgendes geschrieben :

Nach langem Suchen nach einem geeigneten Konversations-"Medium" habe ich mich für DDE entschieden, da es mir dafür passend schien...

Hallo Magic J, DDE verwendet für die Kommunikation Windows Messages.
Damit dies funktioniert, müssen auch noch Desktop und Station identisch sein.

Beides ist unter Verwendung des IIS und ISAPI nicht gegeben.
Programmtechnisch ist es zwar möglich sich in eine User Session (Desktop & Station) reinzuhängen, aber der Aufwand steht nicht dafür.
Auch ist eine Botschaftenbehandlung mit Messageloop (WNDProc) in der DLL erforderlich, da diese der IIS nicht zur Verfügung stellt.

Für IPC mit IIS und oder Services stehen wirkungsvollere und vor allem robustere Möglichkeiten zur Verfügung.

Dies sind Sockets und PIPES!

Mögliche Architektur:

1. In der EXE ein Socket Listener
2. In der ISAPI DLL ein Blocking Client Socket.

Fertig!!

lg. Astat

Magic J - Mo 13.09.10 15:44

---

Vielen Dank für deine ausführliche Antwort!

Werde bei Gelegenheit deine Vorschläge ausprobieren...

Schönen Gruß, Jonas

Zeus. - Di 14.09.10 15:37

---

Von mir auch erstmal ein herzliches Dankeschön!

Astat hat folgendes geschrieben :

Hallo Magic J, DDE verwendet für die Kommunikation Windows Messages. Damit dies funktioniert, müssen auch noch Desktop und Station identisch sein. Beides ist unter Verwendung des IIS und ISAPI nicht gegeben. Programmtechnisch ist es zwar möglich sich in eine User Session (Desktop & Station) reinzuhängen, aber der Aufwand steht nicht dafür. Auch ist eine Botschaftenbehandlung mit Messageloop (WNDProc) in der DLL erforderlich, da diese der IIS nicht zur Verfügung stellt.

Hab ichs doch geahnt! :evil:

Astat hat folgendes geschrieben :

Dies sind Sockets

Daran hatte ich vor Magic Js Lösung mit DDE auch gedacht, nur war mir in dem Moment (aus welchen Gründen auch immer) nicht bewusst, dass BCSs eine Lösung wären. Ich hab eben nur an NBCSs gedacht und dat wars ... :roll:

Astat hat folgendes geschrieben :

1. In der EXE ein Socket Listener 2. In der ISAPI DLL ein Blocking Client Socket.

Du sprichst schon von ganz normalen TCP/IP-Sockets?

Astat hat folgendes geschrieben :

und PIPES!

Was genau meinst du damit jetzt? Sorry, steh grad auf dem Schlauch... Meinst du das [http://de.wikipedia.org/wiki/Pipe_(Informatik)]? Ich denke mal, dass das sicher die performancestärkste Lösung wäre. Dürfte aber bei parallelen Anfragen nicht unbedingt ganz so einfach wie Sockets zu realisieren sein!?


Welche Alternative würdest du nun also empfehlen?

Danke und Gruß,
Zeus.

Martok - Di 14.09.10 19:41

---

Zeus. hat folgendes geschrieben :

Astat hat folgendes geschrieben : und PIPES! Was genau meinst du damit jetzt? Sorry, steh grad auf dem Schlauch... Meinst du [url=http://de.wikipedia.org/wiki/Pipe_(Informatik)]das[/url]?

Genau sowas. Dazu auch CREATEPIPE und verlinkte.

Zeus. hat folgendes geschrieben :

Ich denke mal, dass das sicher die performancestärkste Lösung wäre.

Und Unix ja, Windows-Pipes sind extrem langsam!
Nicht unbedingt vom reinen Durchsatz her (Milchmädchen-Test à la ptime cmd /c "dd if=/dev/zero of=- bs=50k count=500000|dd if=- bs=50k of=nul" liefert im Endergebnis ca 750MB/s, was auch Process Explorer bestätigt), sondern von der Event-Anzahl her. Lässt sich mit diesem Trick messen, indem man kleinere Blöcke verwendet. Man erhält da so ca. 10-15k Blöcke/Sekunde ohne jede Verarbeitung...

An der Stelle sind also Sockets zu bevorzugen. Oder natürlich andere IPC-Lösungen wie Shared Memory, was aber wieder aufwand erfordert um darauf sowas wie ein Protokoll zu bauen. Bei codeproject.com gibts da was, da habe ich aber den Link zu nicht mehr :(

Zeus. hat folgendes geschrieben :

Dürfte aber bei parallelen Anfragen nicht unbedingt ganz so einfach wie Sockets zu realisieren sein!?

In der Tat. Blocking Sockets machen das alles schon, was du mit anderen Techniken mühsam von Hand bauen müsstest.