Czy w delphi można w prosty sposób przesłać obiekt przez gniazda, czy trzeba skonwertować pola obiektu do rekordu i go jako bufor o stałej wielkości przesłać? Używam Tlist i Tstack.
0
0
Obiektu się nie da. Bezsensownym byłoby przesyłanie adresów z nim powiązanych, bo w obszarze pamięci procesu odbierającego nie są one prawidłowe. Możesz przesyłać rekordy lub w ogóle dane; nie koniecznie o stałej wielkości.
0
samego obiektu nie wyślesz, bo nie jesteś w stanie wysłać jego kodu, a nawet jesli jesteś, to nie dasz rady go wykonać (DEP - blokada wykonywania danych na nowszych Windows).
natomiast potrafi to Java.
0
Jeżeli chodzi o wysyłanie obiektów w delphi to jesteś to w stanie zrobić. Ale jak już wcześniej koledzy pisali nie ma sensu np. przesyłać obiektu ktory zawiera wskażniki i tego typu rzęczy bo po drugiej stronie jest bezużyteczne. Jeśli natomiast chodzi o przesyłanie prostych obiektów to pomoże w tym SOAP(Delphi 7 Enterprise to ma). Ale Soap ani też Java(<ort>serjalizacja </ort>obiektów) nie przesyła kodu obiektów. Jeżeli się uprzeć to można też przesłać kod a żeby go potem wykonać trzeba go umieścić w bloku pamięci zaalokowanym przez VirtualAlloc z odpowiednimi parametrami(ŁF jednak się da).
0
Java wysyła kod klasy (za pomocą RMI), więc mylisz się. Co do Delphi - samo zaalokowanie pamięci nie oznacza, że dasz radę wysłać kod obiektu.
0
Java Remote Method Invocation (Java RMI) enables the programmer to create distributed Java technology-based to Java technology-based applications, in which the methods of remote Java objects can be invoked from other Java virtual machines*, possibly on different hosts. RMI uses object serialization to marshal and unmarshal parameters and does not truncate types, supporting true object-oriented polymorphism.
Przepraszam że to poza tematem ale nie mogę tego tak pozostawić. RMI to samo dla java'y co RPC w Windows. RMI(zdalne wywoływanie procedur) nie przesyła kodu wykonywalnego dla VM, ponieważ korzysta z mechanizmu serializacji. To samo można wykonać w delphi wykorzystując (THTTPSoapDispatcher, THTTPSoapPascalInvoker, TWSDLHTMLPublish, ...) ale jak już było powiedziane to nie przesyła kodu procedury między hostami a jedynie przekazuje parametry do procedury ktora ma się wykonać zdalnie a następnie odsyła wynik.
A jeżeli chodzi o przesłanie kodu: to przesłanie procedury lub funkcji ktora nie korzysta z zmiennych/stałych globalnych wydaje się dość proste nie ma adresów które trzeba by było realokować i umieszczenie ich w bloku pamięci którą można "execute".
I tak przykładowo:
function sum(a, b: Integer): Integer;
begin
Result:= a + b;
end;
zostanie przetłumaczone na:
add edx, eax
mov eax, edx
ret
a taki kod po przesłaniu na inny komputer z pewnościu uda się uruchomić.
0
oczywiscie chodzilo mi o przeslanie samych danych, zapytalem, bo wlasnie w javie obiekty przesylalem, ale aby sie nie uzywac komponentow z enterprise przeslalem rekordami...
0
dj napisał(a)
RMI to samo dla java'y co RPC w Windows. RMI(zdalne wywoływanie procedur) nie przesyła kodu wykonywalnego dla VM <ort>poniewarz </ort><ort>kożysta </ort>z mechanizmu serializacji.
No to popatrz na to (http://www.javacoffeebreak.com/articles/rmi_corba/index.html ):
This is an exciting property, because it means that new code can be sent across a network and dynamically loaded at run-time by foreign virtual machines.
To nie jest RPC, bo kod jest wykonywany na lokalnej maszynie, odwrotnie niż RPC, więc pozwala np. podzielić obliczenia na wiele komputerów. Taki projekt robił niedawno Kapustka, jak nie zapomnę to podrzucę mu link do tego tematu, może się wypowie.
dj napisał(a)
A jeżeli chodzi o przesłanie kodu: to przesłanie procedury lub funkcji ktora nie <ort>kożysta </ort>z zmiennych/stałych globalnych wydaje się dość proste nie ma adresów które trzeba by było realokować i umieszczenie ich w bloku pamięci którą można "execute".
No spoko, ale przykład jest banalny. Teraz wyobraź sobie, że masz całą klasę, która ma wiele metod, nie znasz rozmiaru kodu dla żadnej z nich, do tego dochodzi dziedziczenie z innych klas, z którymi jest ten sam problem, do tego jeszcze jakieś pola będące klasami (czyli de facto wskaźnikami).
Nie twierdzę, że przesłanie i wykonanie kodu na innym komputerze przez Delphi jest niemożliwe. Twierdzę, że przesłanie kompletnej klasy graniczy z niemożliwością.
darck napisał(a)
oczywiscie chodzilo mi o przeslanie samych danych
Cichaj ;-)
0
Poczytałem trochę o RMI (zdalne wywoływanie metod) by się upewnić w moim przekonaniu. I gdzieniegdzie jest wspomniane, że owszem można przeprowadzić migracje zdalnego obiektu(czyli przesłać kod obiektu na inną VM) ale tego typu operacji standardowo nie udostępnia RMI a implementacja nie należy do łatwych. Jeżeli chodzi o udział RMI w takim procesie to służy on tylko do wywoływania metod zdalnych klas, ale to już inna sprawa. Taki sam efekt można uzyskać stosując soap jeżeli wcześniej uda nam się przesłać obiekt z jadnej app do drugiej. W tej sytuacji poprawne przesłanie obiektów z jednaj app do drugiej jest zadaniem trudnym <ort>zaruwno </ort>w Java'ie jak i w Delphi jednakże Java może udostępniać kilka metod ktore w tym pomagają. Oczywiście na trudność problemu przesłania obiektu wpływa także jego budowa wewnętrzna.
Żeby nie pozostać gołosłownym tu to jest link: http://www.skynet.com.pl/~azaghal/java_sem/referat_rmi.htm
0
ech... przeczytałeś chociaż co było pod linkiem, który podałem? może Kapustce będzie się chciało podać Ci konkrety żeby Ci udowodnić że nie masz racji. ale punkt dla Ciebie - RMI faktycznie przede wszystkim służy do tego samego, co RPC. ale nie tylko... na bazie RMI można względnie łatwo zbudować zdalne wykonywanie lokalnego kodu. Kapustka, pomóż przekonać niewiernego ;-)
0
Łukasz, dzięki że pamiętałeś o moim projekcie !
Jest to system do rozpraszania obliczeń w zdecentralizowanej sieci P2P pomyślany jako middleware. Programista wybiera czynności programu, które chce rozproszyć i dla każdej z nich tworzy klasę (jest to w istocie wzorzec projektowy command). Zlecenie obliczeń polega na przesłaniu instancji takiej klasy a wyniki są odbierane asynchronicznie zgodnie ze wzorcem observer.
Zadania obliczeniowe są więc obiektami, które faktycznie przemieszczają się pomiędzy JVM. W tym projekcie przyjąłem bardzo silne uproszczenie: wędrujące klasy nie mają referencji do innych obiektów. System nawet z tym ograniczeniem wydaje się spełniać swoje cele a ja mam wiele innych problemów do rozwiązania związanych z zawodnością sieci P2P oraz strategią zrównoważania obciążenia.
Najbardziej problematyczne było założenie, że komputer który jest odbiorcą może nie znać definicji klasy której obiekt właśnie otrzymuje. Java częściowo obsługuje taką sytuację poprzez klasę URLClassLoader, niestety to wymaga postawienia serwera HTTP lub FTP na komputerze który wysyła obiekt. To koliduje z najważniejszym aspektem platformy - przyjaznością.
Aby to objeść wprowadziłem regułę, że nadawca musi na chwilę przed wysłaniem obiektu ostrzec odbiorcę, że wskazana klasa zostanie wysłana. Dzięki temu odbiorca ma szansę aby poprosić o bytecode tej klasy, zinterpretować go i dynamicznie dodać do JVM.
Omówione właśnie wysyłanie obiektów opiera się na serializacji obiektów. RMI nie jest technologią do przesyłania obiektów bowiem służy do wywołania metod na ZDALNYM obiekcie. Nie występuje tutaj przemieszczanie się obiektu między środowiskami wykonawczymi. Proponuję spojrzeć na RMI jako na wygodne opakowanie komunikacji Socketowej, które pozwala nam programować na wyższym poziomie abstrakcji niż strumienie bajtów. W systemie używam RMI aby kontaktować się z klasą reprezentującą zdalny węzeł i przekazać jej obiekt reprezentujący partię obliczeń do wykonania.
Na koniec warto wspomnieć, że serializacja javy jest kompletna - referencje są również serializowane. Powodem dla którego zgodziłem się na wspomniane uproszeczenie jest wysokie prawdopodobieństwo, że odbiorca nie będzie znał definicji referencyjnych klas ... Przychodzi mi do głowy agresywniejsze ingerowanie w strukturę classLoaderów ale sprawy się komplikują ze względu na środowisko P2P - kogo bowiem należy wypytać o definicję klasy ?
pozdrawiam.