2011-12-29 11 views
5

Dobry wieczór. Szukam metody udostępniania danych z mojej aplikacji w całym systemie, aby inne aplikacje mogły odczytać te dane, a następnie zrobić z nimi, co chcą (np. Sformatować je w celu wyświetlenia, użyć do logowania itp.). Dane muszą być aktualizowane dynamicznie w samej metodzie.System udostępniania danych szeroki

Najpierw przychodziło na myśl WMI, ale wtedy masz problem z pauzowaniem aplikacji podczas czytania z WMI. Ponadto, nie mam pojęcia, jak ustawić własną przestrzeń nazw lub klasy, jeśli jest to możliwe nawet w Delphi.

Używanie plików to kolejny pomysł, ale może to spowodować duże obciążenie dysku i jest to naprawdę okropna metoda do wykorzystania w czasie rzeczywistym.

Korzystanie z sterownika prawdopodobnie byłoby najlepszą opcją, ale to trochę zbyt nachalne na koniec użytkowników, jak na mój gust, i nie mam pojęcia, od czego zacząć.

WM_COPYDATA byłby świetny, ale nie jestem pewien, czy to wystarczająco dynamiczne, i czy będzie duże zasoby, czy nie.

Używanie protokołu TCP/IP byłoby najlepszym wyborem dla całej sieci, ale oczywiście jest mało przydatne, gdy działa w jednym systemie bez wymagań sieciowych.

Jak widać, staram się dowiedzieć, co z tym zrobić. Nie chcę wchodzić w jedną tylko metodę, aby się przekonać, że to się nie uda. Zasadniczo coś w rodzaju usługi lub procesu w tle, aby nagrać dane, a następnie pozwolić innym aplikacjom na odczytanie tych danych. Nie jestem pewien metod. Wolałbym NIE UŻYWAĆ elewacji/UAC, ale jeśli zajdzie taka potrzeba, to ja się na to zgodzę.

Używam w Delphi 2010 do tego ćwiczenia.

Wszelkie pomysły?

+0

Czy mógłbyś użyć bazy danych? –

+0

Myślę, że potrzebne są dodatkowe wyjaśnienia dotyczące "całego systemu". Czy musisz wchodzić w interakcje z innymi sesjami (użytkownikami zalogowanymi do tego samego systemu za pomocą "przełącznika użytkownika", pulpitu zdalnego, Citrix itp.) Lub po prostu bieżącego logowania? Lub podsystemy VM? Nie sądzę, że WM_CopyData będzie działać w takich granicach, więc powinieneś wyjaśnić zakres. –

+0

Cześć Chris. Nie muszę w żaden sposób wchodzić w interakcje z innymi sesjami lub maszynami wirtualnymi ani przekazywać ich. Jest to transmisja podczas sesji, na którą patrzę. –

Odpowiedz

5

Chcesz stworzyć jakiś architekturze klient-serwer, który jest zwany również IPC.

Używanie WM_COPYDATA to bardzo dobry pomysł. Odkryłem, że jest bardzo szybki, lekki i wydajny na lokalnej maszynie.I może być nadawany przez system, do wszystkich aplikacji jednocześnie (należy używać z ostrożnością, jeśli jakaś aplikacja nie obsługuje go poprawnie).

Można również udostępniać niektóre pamięci przy użyciu plików mapowanych w pamięci. Może to być najszybsza opcja IPC dla ogromnej ilości danych, ale synchronizacja jest nieco skomplikowana (jeśli chcesz udostępnić więcej niż jeden bufor na raz).

Nazwane rury są dobrymi kandydatami do lokalnych. Zwykle są trudne do wdrożenia/skonfigurowania w sieci, ze względu na problemy bezpieczeństwa w nowoczesnych wersjach systemu Windows (i używają protokołu TCP/IP do komunikacji sieciowej - należy więc zamiast tego używać bezpośrednio protokołu TCP/IP).

Moja osobista porada jest taka, że ​​należy wdrożyć udostępnianie danych za pomocą klas abstrakcyjnych, które mogą dostarczyć kilka implementacji. Najpierw możesz użyć WM_COPYDATA, a następnie przejść do nazwanych potoków, TCP/IP lub HTTP, aby rozpowszechniać aplikację w sieci.

Dla naszego ORM typu klient-serwer Open Source, we implemented several protocols, w tym WM_COPY_DATA, nazwanego potokiem, HTTP lub bezpośredniego dostępu wewnątrzprocesowego. Możesz rzucić okiem na kod źródłowy podany dla wzorców implementacji. Oto kilka punktów odniesienia, w celu uzyskania danych z rzeczywistych wdrożeń:

Client server access: 
    - Http client keep alive: 3001 assertions passed 
    first in 7.87ms, done in 153.37ms i.e. 6520/s, average 153us 
    - Http client multi connect: 3001 assertions passed 
    first in 151us, done in 305.98ms i.e. 3268/s, average 305us 
    - Named pipe access: 3003 assertions passed 
    first in 78.67ms, done in 187.15ms i.e. 5343/s, average 187us 
    - Local window messages: 3002 assertions passed 
    first in 148us, done in 112.90ms i.e. 8857/s, average 112us 
    - Direct in process access: 3001 assertions passed 
    first in 44us, done in 41.69ms i.e. 23981/s, average 41us 
    Total failed: 0/15014 - Client server access PASSED 

Jak widać, najszybszy jest bezpośredni dostęp, a następnie WM_COPY_DATA, potem nazwane potoki, a następnie HTTP (tj TCP/IP). Wiadomość zawierała około 5 KB danych JSON zawierających 113 wierszy, pobranych z serwera, a następnie przeanalizowanych na kliencie 100 razy (tak, nasz framework jest szybki :)). W przypadku dużych bloków danych (np. 4 MB), WM_COPY_DATA jest wolniejsze niż nazwane potoki lub HTTP-TCP/IP.

+0

Dzięki za to Arnaud. Zdecydowanie wygląda na to, że lokalne komunikaty Windows byłyby najłatwiejszą i najbardziej wydajną metodą. Dane, które wysyłam, będą miały tylko 3 wartości po 3 bajty, a następnie potencjalnie 5 ciągów o łącznej wartości mniejszej niż 100 bajtów i kolejnych 8 ciągów o długości od 1 do 50 bajtów. Całkowita liczba wysłanych wiadomości będzie mniejsza niż 1 KB, ale niektóre wartości będą aktualizowane bardzo często (w niektórych przypadkach <250 ms). –

+0

@ Scott'Chron'Pritchard Masz rację, to jest dokładnie ten rodzaj danych, które bardzo sprawnie przetwarza wiadomość GDI. Cały system Windows UI polega na milionach takich wiadomości przetworzonych tak szybko, jak to możliwe. Dla lokalnej komunikacji będzie to najlepsze rozwiązanie. –

2

Gdzie jest kilka metod IPC (komunikacja międzyprocesowa) w systemie Windows. Twoje pytanie jest raczej ogólne, mogę zaproponować pliki mapowane w pamięci do przechowywania twoich udostępnionych danych i transmisji wiadomości przez PostMessage, aby poinformować inną aplikację, że zmienione dane zostały zmienione.

2

Jeśli nie masz nic przeciwko uruchomieniu innego procesu, możesz użyć jednej z baz danych NoSQL.

Jestem prawie pewien, że wielu z nich nie będzie miało sterowników Delphi, ale niektóre z nich mają sterowniki REST, a zatem mogą być sterowane z praktycznie dowolnego miejsca.

0

Wyszukiwanie dla "komunikacji międzyprocesowej delphi" da ci wiele wskazówek.

Proponuję spojrzeć na http://madshi.net/, zwłaszcza MadCodeHook (http://help.madshi.net/madCodeHook.htm)

mam dobre doświadczenia z produktem.

Powiązane problemy