klastry obliczeniowe

34

maj 2004

Rozproszone fraktale

Marek Sawerwain

O

soby, które zajmują się
grafiką, a w szczególno-
ści techniką śledzenia
promieni, często mogą

powiedzieć, że moc obliczeniowa ich
komputerów nie jest wystarczająca.
Dotyczy to także rysowania fraktali,
szczególnie tych o skomplikowanych
wzorach. W tym artykule chciałbym
pokazać, jak rozdzielić zadanie ryso-
wania tego typu obiektów na kilka
komputerów za pomocą technologii
rozproszonych obiektów – CORBA.
Napiszemy nieskomplikowany program
tworzący coś w rodzaju klastra przezna-
czonego do rysowania fraktali.

Wbrew pozorom, proces rysowa-

nia fraktali jest bardzo pracochłonny
i tylko najbardziej popularne zbiory,
takie jak Mandelbrot, Julia czy Newton,
można narysować w czasie rzeczywi-
stym. Po wprowadzeniu kilku uprosz-
czeń, można nawet pokusić się o ich
animację. W innych przypadkach jest
to proces bardzo czasochłonny. Dość
łatwo można go przyspieszyć, gdy
sam proces rysowania podzielimy na
regiony i rozdzielimy na kilka kompu-
terów.

Kilka postanowień na

początek

Pierwsza decyzja, którą trzeba podjąć,
dotyczy języków programowania uży-
tych do napisania systemu. Serwer zosta-
nie napisany przy pomocy języka Python
i systemu CORBA OmniORB.

Dlaczego Python? Nasz system,

pomimo swoich niewielkich rozmiarów,
ma być systemem uniwersalnym i zdol-

nym do rysowania dowolnych fraktali
opartych o tzw. funkcję ucieczki. Python,
jak każdy język skryptowy, nie oferuje
wysokiej wydajności, ale posiada pewne
interesujące nas cechy, a jedną z nich
jest możliwość zdefiniowania funkcji
w czasie wykonania skryptu. Dzięki tej
własności serwer będzie odbierał od
klienta kod źródłowy funkcji i instalował
ją we własnym środowisku.

Powód, dla którego za system

CORBY po stronie serwera został
wybrany pakiet OmniORB, jest bardzo
prozaiczny. Obecnie oferuje on najlep-
szą wersję CORBY dla języka Python.
Można w nim bez zbędnych kłopotów
korzystać z usługi nazw, która ma zna-
czenie zasadnicze dla naszego klastra
rysującego fraktale.

Zastanówmy się teraz nad progra-

mem klienta. Może on być napisany
w dowolnym języku i dowolnym systemie
CORBY, zgodnym ze standardem adapte-
ra POA oraz obsługującym dynamiczne
wywołania metod (DII – Dynamic
Invocation Inteface). Takim serwerem
jest również OmniORB, ale aby pokazać
elastyczność technologii rozproszonych
obiektów, zastosujemy inny system
o nazwie MICO. Oprócz zastosowania
innego systemu CORBA, program klienta
zostanie napisany w innym języku, gdyż
będzie to C++.

Ostatni problem to: w jaki sposób

rozproszyć proces rysowania fraktala na
kilka komputerów? Zastosowany algo-
rytm rysuje fraktal linia po linii. Oznacza
to, że możemy bez problemów podzielić
cały proces rysowania na kilkanaście
komputerów rozdzielając im poszczegól-

O autorze

Autor zajmuje się tworzeniem

oprogramowania dla WIN32

i Linuksa. Zainteresowania:

teoria języków programowania

oraz dobra literatura. Kontakt

z autorem:

[e-mail].

Na płycie CD/DVD

Na płycie CD/DVD znajdują

się pliki źródłowe napisanego

programu, jak również wszystkie

listingi.

35

www.linux.com.pl

klastry obliczeniowe

corba

ne wiersze rysowanego obrazu. Klient
przy pomocy usługi nazw pobierze listę
zarejestrowanych węzłów i do każdego
wyśle odpowiednią ilość wierszy do
narysowania. Po otrzymaniu wyników
połączy pojedyncze wiersze w jeden
rysunek. Schematycznie zostało to przed-
stawione na Rysunku 1.

Definicja interfejsu

dfractal

Podczas pisania jakichkolwiek aplikacji
w technologii CORBA należy w pierwszej
kolejności określić interfejs obiektów roz-
proszonych. Nasz interfejs o nazwie

calc_

node

to tylko cztery metody. Jego defini-

cja znajduje się na Listingu 1. Czynności,
które wykonują poszczególne metody, są
następujące:

•

setup_iter_func

– określa postać

funkcji ucieczki;

•

setup_render_size

– określa wymia-

ry obrazu, na którym będzie rysowa-
ny fraktal (w pikselach);

•

render_one_row

– rysuje wiersz o nu-

merze

y

od pozycji

from_x

do

to_x

;

•

quit

– wywołanie tej funkcji powodu-

je zakończenie pracy węzła.

Posługiwanie się tym interfejsem jest
trywialne, np. w Pythonie, gdy chcemy
narysować cały fraktal, to w pierwszej
kolejności ustalamy wymiary oraz poda-
jemy kod funkcji ucieczki:

calc_node.setup_render_size(300,200)
calc_node.setup_iter_func(funkcja_ucieczki)

Następnie przy pomocy zwykłej pętli

while

wywołujemy metodę

render_one_

row

. Wynikiem tej metody jest jeden

wiersz obrazu. Kolory zostały zakodo-
wane w postaci trójek RGB, więc mamy
gotowe dane do bezpośredniego przenie-
sienia na ekran lub zapisu do pliku:

row=0
while row<=200:
dane=calc_node.render_one_

S

row(row,0,300)

for i in dane:
print i
row=row+1

Tworzymy serwer

Aplikacje w CORBIE są dzielone na dwie
części: serwer i klient. Prace nad naszym
systemem zaczniemy od napisania serwe-
ra, gdyż, wbrew pozorom, to mniej skom-
plikowane zadanie.

W pierwszej kolejności trzeba

poddać kompilacji plik z interfejsem,
gdyż tego wymaga odwzorowanie
OmniORB dla Pythona. Polecenie jest
następujące:

omniidl -bpython dfractal.idl

Po kompilacji pliku z interfejsem, utwo-
rzone pliki dołączamy słowem

import

.

Dołączenie wszystkich modułów konie-
cznych do poprawnej pracy serwera to
tylko trzy linie kodu:

from omniORB import CORBA, PortableServer
import CosNaming
import dfractal, dfractal__POA

W pierwszej linijce dołączamy moduły
bezpośrednio związane z danym syste-
mem CORBY, czyli w naszym przypad-
ku OmniORB. Druga linia dołącza inter-

Rysunek 1.

Schemat „klastra” rysującego fraktal

Instalacja pakietów

OmniORB oraz MICO

Autorzy obydwu pakietów przygotowali
skrypty configure, więc kompilacja prze-
biega według typowej ścieżki postępo-
wania:

./configure –prefix=/katalog/

S

gdzie/ma/zostać/zainstalowany/pakiet
make
make install

Również pakiet z wersją systemu
OmniORB dla języka Python o nazwie
omniORBpy posiada skrypt configure.
Oczywiście, warto mieć zainstalowane-
go Pythona w stosunkowo nowej wersji
2.2 albo 2.3.

36

maj 2004

klastry obliczeniowe

fejs odpowiedzialny za usługę nazw.
W trzeciej linii dołączamy nasz interfejs
oraz wygenerowany szkielet do imple-
mentacji serwera.

Kod całego serwera znajduje się na

płycie CD/DVD, ale Listing 2 zawiera
jego najważniejsze fragmenty. Jak widać,
została usunięta definicja klasy

Fractal-

Render

. Powrócimy do niej w następnym

punkcie.

Każdy, kto choć raz napisał najmniej-

szy program w technologii CORBA, od
razu pozna charakterystyczne elementy
występujące w programie serwera – pro-
gramy w CORBIE są do siebie bardzo
podobne, pomimo różnych serwerów
CORBY czy zastosowanego języka pro-
gramowania.

Centralnym elementem naszego sys-

temu renderingu jest usługa nazw. W ser-
werze oraz w kliencie musimy podać
adres symboliczny bądź numer IP, pod
którym znajduje się ta usługa. Z tego
powodu przed uzyskaniem odniesienia
do obiektu

orb

, zmiennej zawierającej

argumenty podane w linii poleceń, wpi-
sujemy adres maszyny, na której urucho-
miono usługę nazw:

sys.argv.extend([‘-ORBInitRef’,

S

‘NameService=corbaname::127.0.0.1’])

Jak widać z powyższego przykładu,
odwołujemy się do lokalnej maszyny,
więc używając tego systemu w rzeczywi-
stej sieci, trzeba zmienić tę linię kodu.

Wcześniej

wykonujemy

jeszcze

jedną istotną czynność, a mianowicie
odczytujemy podaną nazwę nasze-
go węzła. Nazwy dla poszczególnych
węzłów muszą być oczywiście inne –
w ten sposób je rozróżniamy. Proces
rejestracji naszego węzła w usłudze nazw
rozpoczynamy od uzyskania odniesie-
nia do usługi nazw. Pomimo, że serwer

jest pisany w Pythonie, to następujący
kod jest prawie identyczny z tym, który
omówię przy okazji klienta (napisanego
przy pomocy języka C++):

ns = orb.resolve_initial_references

S

(„NameService”)
root_ctx = ns._narrow

S

(CosNaming.NamingContext)

Sam proces rejestracji obiektu poprzedza-
my jego wstępnym utworzeniem:

servant = CalcNodeServant()
objref = servant._this()

Gdy w zmiennej

objref

mamy już refe-

rencję do obiektu, to wystarczy utwo-
rzyć obiekt nazwy bazujący na typie

CosNaming.NameComponent

oraz dokonać

jego rejestracji metodą

bind

obiektu

root_ctx

:

name = [CosNaming.NameComponent

S

(„calc_node”, node_name)]
root_ctx.bind(name, objref)

Ostateczna aktywacja serwera to typowy
kod dla dowolnego serwera CORBY.
Dokonujemy aktywacji adaptera POA:

poa._get_the_POAManager().activate()

oraz uruchamiamy cały serwer:

orb.run()

.

Jak widać na Listingu 2, pomiędzy tymi
poleceniami został jeszcze utworzony
obiekt typu

FractalRender

.

Dzięki zdefiniowaniu oddzielnej klasy

do rysowania samego fraktala, poszczegól-
ne metody obiektu

CalcNodeServant

są

bardzo krótkie i nie zawierają zbyt skom-
plikowanej treści. Wszystkie odwołują się
do globalnego obiektu

fractal

. I to on

wykonuje całą „robotę” związaną z obsłu-
gą procesu rysowania. Wyróżnia się tylko
metoda

quit

, kończąca działanie naszego

serwera. Dokonuje ona także zwolnienia

nazwy, pod którą konkretny serwer jest
reprezentowany w usłudze nazw.

Rysowanie fraktala

Rysowanie fraktala to zadanie klasy

FractalRender

. Znaczenie poszczególnych

metod jest następujące:

•

ResetParam(_maxx, _maxy)

– ustala

wymiary rysunku fraktala w pik-
selach, współrzędne początku oraz
wymiary przestrzeni zespolonej, na
której powstaje fraktal;

•

S e t u pIt e r F u n c ( c o d e _ o f_ f u n c)

– tworzy funkcję ucieczki (iteracji);

•

RenderOneLine(render_y,

from_x,

to_x)

– rysuje pojedynczy wiersz,

wartością wynikową jest lista z kolo-
rami w formacie RGB.

W rzeczywistości w kodzie są jeszcze
dwie dodatkowe metody:

RenderFrag-

ment

, przeznaczona do rysowania frag-

mentu fraktala, oraz

DrawFullFractal-

MandelbrotStyle

, rysującą cały fraktal.

Obydwie, identycznie jak

RenderOneLi-

ne

, dają w wyniku listę z kolorami w for-

macie RGB.

Zastosowany algorytm należy do

najprostszych technik rysowania frak-
tali, która polega na tym, że rysowanie

Listing 1.

Definicja interfejsu dfractal

module dfractal{

typedef sequence

<long> TRow;

interface calc_node{

void

setup_iter_func(

in string code

);

void

setup_render_size(

in

long width,

in

long height

);

TRow render_one_row(

in

long y,

in

long from_x,

in

long to_x

);

void

quit();

};
};

Format pliku PNM

Pliki w formacie PNM (obsługiwany
bez problemów przez GIMP-a) mają
bardzo prostą strukturę. Do naszych
potrzeb wystarczy plik PNM o typie P3.
Jest to w pełni tekstowy format. Jego
nagłówek zaczyna się w następują-
cy sposób:

P3
# CREATOR: narysowane przez dfrac-
tal
100 100

W pierwszej linii zawarty jest typ pliku.
P3 oznacza, że będzie to w plik w for-
macie wyłącznie tekstowym. Następ-
nie podajemy komentarz – można w
nim umieścić krótką informację, kto
utworzył plik. W trzeciej linii nagłówka
podajemy dwie liczby – są to wymiary
rysunku: szerokość oraz wysokość. Po
tak skonstruowanym nagłówku poda-
jemy kolejne wartości pikseli, opisa-
ne za pomocą trójek RGB. Poszcze-
gólne wartości znajdują się w oddziel-
nych liniach.

37

www.linux.com.pl

klastry obliczeniowe

corba

w przestrzeni zespolonej rozpoczynamy
od lewego górnego rogu i linia po linii
dla każdego punktu na wydzielonym
wcześniej obszarze sprawdzamy, jaką
wartość ma funkcja ucieczki.

Cały kod funkcji rysującej wskaza-

ny wiersz zawiera Listing 3. Ma ona trzy
części.

W pierwszej części ustalamy wymia-

ry rysunku w pikselach: zmienne

vWidth

i

vHeight

. Zmienne

vfromX

i

vfromY

zawierają współrzędne lewego górne-
go rogu. Początkowe wartości zawie-
rają zmienne z przedrostkiem „new”.
Ich wartość zostaje określona metodą

ResetParam

w momencie wywoła-

nia metody

setup_render_size

obiektu

calc_node

. Ostatnie dwa przypisania do

kx

i

ky

określają krok, o jaki będą zwięk-

szane współrzędne zespolone. W przy-
padku rysowania wiersza istotna jest
tylko zmienna

kx

.

W części drugiej obliczamy przesu-

nięcia względem osi

x

oraz

y

, oczywi-

ście w przestrzeni zespolonej (mimo,
że mówimy o liczbach zespolonych, to
wszystkie obliczenia bazują na warto-
ściach rzeczywistych). Obliczenia dla
zmiennej

yy

polegają na tym, że podany

numer wiersz

render_y

jest mnożo-

ny przez wartość kroku

ky

i dodawany

do zmiennej zawierającej współrzędne

lewego górnego rogu

vfromY

. Ta część

funkcji wyznacza też początek rysowa-
nia w danym wierszu (początek zawie-
ra zmienna

xx

, a miejsce zakończenia

vtoX

). Oznacza to, iż metoda

RenderOne-

Line

umożliwia także rysowanie dowol-

nego fragmentu podanej linii.

Po

wyznaczeniu

współrzędnych

danego wiersza w części trzeciej pozostaje
nam tylko przy pomocy nieskomplikowa-
nej pętli przejść wzdłuż osi

x

po poszcze-

gólnych punktach należących do danego
wiersza i dla każdego wywołać funkcję

iter,

czyli funkcję ucieczki. Dopiero

w argumencie tej funkcji pojawia się kon-
struktor

complex

, który ze współrzędnych

xx

i

yy

tworzy liczbę zespoloną.

Wynikiem funkcji

RenderOneLine

jest lista zawierająca poszczególne trójki
RGB, opisujące kolory. Lista tworzona jest
w bardzo prosty sposób. Na początek two-
rzymy listę pustą, a następnie po wyzna-
czeniu wartości kolorów dodajemy te
wartości do listy. W tym miejscu podczas
wyznaczania wartości kolorów ujawnia się

Rysunek 2.

Diagram przepływu

sterowania w programie klienta

Listing 2.

Fragmenty skryptu Pythona implementującego serwer calc_node

#! /usr/bin/python

import sys

from omniORB

import CORBA, PortableServer

import CosNaming

import dfractal, dfractal__POA

class

FractalRender:

# usunięta definicja klasy rysującej fraktal

class

CalcNodeServant(dfractal__POA.calc_node):

global

fractal

print

„setup_iter_func”, code

fractal.SetupIterFunc(code)

def

setup_render_size(self, width, height):

global

fractal

fractal.ResetParam(width, height)

print

„setup_render_size w”,width,”h”,height

def

render_one_row(self, y, from_x, to_x):

print

„begin render”,y,from_x, to_x

r=fractal.RenderOneLine(y,from_x, to_x)

print

„end render”,y,from_x, to_x

return

r

def

quit(self):

global

orb, root_ctx

root_ctx.unbind(name)

print

„node stop ...”

orb.shutdown(

0

)

if

len(sys.argv)>

1:

node_name=sys.argv[

1

]

else:

print

„proszę podać nazwę węzła”

sys.exit(

0)

sys.argv.extend([‘-ORBInitRef’, ‘NameService=corbaname::

127.0.0.1’]

)

orb = CORBA.ORB_init(sys.argv, CORBA.ORB_ID)
poa = orb.resolve_initial_references(

„RootPOA”

)

ns = orb.resolve_initial_references(

„NameService”

)

root_ctx = ns._narrow(CosNaming.NamingContext)
servant = CalcNodeServant()
objref = servant._this()
name = [CosNaming.NameComponent(

„calc_node”, node_name

)]

try:

root_ctx.bind(name, objref);

except

CosNaming.NamingContext.AlreadyBound:

root_ctx.rebind(name, objref)

print

„Name calc_node [„,node_name,”] already existed -- rebound”

poa._get_the_POAManager().activate()
fractal=FractalRender()
orb.run()
print

„... end work ...”

38

maj 2004

klastry obliczeniowe

pewna niedoskonałość. Sposób wyzna-
czania kolorów, który bazuje na reszcie
z dzielenia, nie daje zbyt efektownych
układów kolorystycznych, więc zadaniem
dla Czytelnika jest napisanie dodatkowej
funkcji kolorującej fraktal.

Definiowanie funkcji

ucieczki (iteracji)

Zajmijmy się teraz metodą, która pozwa-
la na ustalenie postaci funkcji ucieczki,
gdyż to ta funkcja odgrywa najważniej-
szą rolę podczas rysowania różnych frak-
tali. Treść metody

SetupIterFunc

wbrew

pozorom jest zaskakująco krótka:

def SetupIterFunc(self, code_of_func):
code_of_iter_func=compile(code_of_

S

func, „<string>”, „exec”)
eval(code_of_iter_func,globals())

W pierwszej linii dokonujemy kompi-
lacji funkcji, więc warto przed rozpo-
częciem procesu rysowania dokładnie
sprawdzić, czy funkcja iteracji została
napisana bezbłędnie. Funkcję kompilu-
jemy w tzw. trybie wykonawczym (trzeci
parametr przyjmuje wartość exec). Po
wykonania funkcji

compile

otrzymujemy

obiekt reprezentujący kod, który można
wykonać przy pomocy funkcji

eval

.

Istotne jest, aby w drugim argumencie
tej funkcji podać jako argument funkcję

globals()

. Spowoduje to, iż nasza funkcja

(o nazwie

iter

, bowiem taka nazwa

występuje w metodzie

RenderOneLine

)

zostanie zdefiniowana w podstawowej
(głównej) przestrzeni, a więc będzie
widziana w każdej klasie.

Funkcja

iter

, oprócz nazwy, przyj-

muje tylko jeden parametr, który jest
liczbą zespoloną zbudowaną w oparciu
o współrzędne punktu w układzie zespo-
lonym. Przykład takiej funkcji rysującej
zbiór Mandelbrota zawiera Listing 4.

Program klienta

Program klienta jest niewiele większy niż
kod źródłowy serwera. Mimo, że to tylko
5 kB tekstu, to również omówimy tylko
jego najciekawsze fragmenty. W analizie
programu klienta pomocny będzie rów-
nież schemat z Rysunku 2.

Pierwsze zadanie naszego klien-

ta to odczytanie z usługi nazw wszyst-
kich węzłów, które są dostępne. Milczą-
co zakładamy, że będą to tylko węzły

calc_node

– uprości to nasz program.

Po przygotowaniu listy węzłów

możemy „rozdać” poszczególne wier-
sze obrazu do narysowania. I tu pojawia
się poważny problem. Wywołania metod
CORBY zazwyczaj działają w trybie syn-
chronicznym, czyli wywołanie jakiejś
metody powoduje wstrzymanie pracy
klienta do czasu, gdy serwer odpowie na
wywołanie określonej metody. Nie jest to
dobre rozwiązanie dla naszego klienta, bo
my chcemy rozdać cały zbiór poszczegól-
nych wierszy do rysowania, a dopiero po
tej czynności poczekać na gotowe dane,
aby ostatecznie połączyć wszystkie wier-
sze w jeden obraz. CORBA oferuje odpo-
wiednie rozwiązanie i jest to technika DII,
o której wspomniałem na początku arty-
kułu. Dynamiczne wywołania pozwala-
ją wywołać zdalną metodę w tzw. trybie
o opóźnionej odpowiedzi. Praca progra-
mu klienta nie jest w takim przypadku
wstrzymywana na czas wykonania zdal-
nej metody, ale to na programie klienta
spoczywa obowiązek odbioru danych.

Klient CORBY, który stosuje DII, nie

musi korzystać z dodatkowych plików
IDL. Z tego powodu nie dokonuje-
my wstępnej kompilacji naszego inter-
fejsu. Trzeba jednak utworzyć specjalny
identyfikator, który pozwoli nam rozpo-
znać dane otrzymane od metody serwe-
ra

render_one_line

(będzie to oczywiście

wiersz z kolorami RGB). Musimy utworzyć
tzw.

TypeCode

i wygląda to następująco:

CORBA::TypeCode_ptr _my_tc_longseq;
_my_tc_longseq=CORBA::TypeCode::

S

create_sequence_tc(0, CORBA::_tc_long);

Pozostałe typy danych należą do podsta-
wowych typów CORBY, więc nie trzeba
stosować dodatkowych zabiegów, aby
z nimi współpracować. Do pracy nasze-
go klienta potrzebujemy listę wszystkich
węzłów. Najlepiej skorzystać z typu

vector

:

vector<CORBA::Object_var> nodes;

Potrzebny jest jeszcze jeden typ, gdyż
podczas procesu przydzielania wierszy do
rysowania będziemy tworzyć listę aktyw-
nych wywołań. Definicja jest następująca:

typedef struct {
CORBA::Request_var req;
CORBA::Long y,from_x,to_x;
int m;
} TRequest;

Definicja listy, a dokładniej wektora oraz
iteratora niezbędnego do przeglądania,
jest następująca:

vector<TRequest> reqs;
vector<TRequest>::iterator reqsIter;

Pierwsza z istotnych czynności to uzy-
skanie od usługi nazw listy wszystkich
węzłów. Fragment z kodu klienta przed-
stawia Listing 5. Listę węzłów odczytuje-
my wywołaniem

root_ctx->list(0, bl,

bi);

(zero oznacza, że otrzymamy wszyst-

kie wpisy w usłudze nazw), a następnie

Listing 3.

Metoda klasy

FractalRender

rysująca jeden wiersz należący do
określonego fraktala

def RenderOneLine

(

self, render_y,

S

from_x, to_x

):

# część I

self.vWidth

=

self.newvWidth

;

self.vHeight

=

self.newvHeight

;

self.vfromX

=

self.newvfromX

;

self.vfromY

=

self.newvfromY

;

self.kx

=

self.vWidth/self.maxx

;

self.ky

=

self.vHeight/self.maxy

;

# część II

xx

=

self.vfromX

+ (

from_x

*

self.kx

)

yy

=

self.vfromY

+ (

render_y

*

S

self.ky

)

self.vtoX

=

self.vfromX

+

S

(

to_x

*

self.kx

);

# część III

row

=[]

while

(

xx

<=

self.vtoX

):

tc

=

iter

(

complex

(

xx,yy

));

r

=(

tc

*

128

) %

256

;

g

=(

tc

*

32

) %

256

;

b

=(

tc

*

64

) %

256

;

row.append

(

r

)

row.append

(

g

)

row.append

(

b

)

xx

=

xx

+

self.kx

return

row

Listing 4.

Przykład funkcji iteracji

odpowiedzialnej za rysowanie zbioru
Mandelbrota

moja_funkcja

=

”””

def

iter(c):

i=

0

z=complex(

0

,

0

);

while

(i <

128

and (z.real*z.real

S

+ z.imag*z.imag) <

4

):

z=(z*z)+c
i=i+

1

return

i

”””

;

39

www.linux.com.pl

klastry obliczeniowe

corba

w pętli za pomocą

resolve

otrzymujemy

odniesienia do obiektów typu

CORBA::

Object_var

. Przy okazji w zmiennej

max_

nodes

zliczamy ilość dostępnych węzłów.

Wartość ta będzie nam potrzebna pod-
czas dystrybucji poszczególnych wierszy
do węzłów.

Z poziomu funkcji

main

wystarczą

nam już tylko dwa wywołania następu-
jących funkcji:

setup_nodes(moja_funkcja, 320, 200);
render_fractal(„rysunek.pnm”, 320, 200);

Pierwsza ustali nam niezbędne począt-
kowe parametry, takie jak wymiary oraz
postać funkcji iteracji, natomiast druga
wykona całą „czarną” robotę, czyli nary-
suje fraktal oraz zapisze go w formacie
PNM (więcej informacji o tym formacie
w ramce Format pliku PNM).

Ustalanie parametrów

początkowych

Treść funkcji

setup_nodes

to tylko pętla

„przebiegająca” po wszystkich węzłach
i ustalająca potrzebne parametry. Przed-
stawia się ona następująco:

for(int i=0;i<max_nodes;i++){
setup_iter_func(nodes[i],

S

moja_funkcja);
setup_render_size(nodes[i], w, h);
}

Ponieważ ustalanie parametrów to
proces łatwy dla poszczególnych serwe-
rów, więc nie ma potrzeby stosowania
wywołania o opóźnionej odpowiedzi
– wystarczy standardowy tryb synchro-
niczny. Treść funkcji

setup_render_size

to Listing 6. Nawet dla osób nie zna-
jących CORBY jest ona czytelna. Para-
metr

obj

reprezentuje zdalny obiekt

zapisany na liście

nodes

. W funkcji sto-

sujemy metodę

_request

z argumentem

w postaci ciągu znaków reprezentujących
nazwę metody, którą chcemy wywołać.
Następnie musimy określić parametry
metody. Mamy tylko dwa: szerokość (

w

)

oraz wysokość (

h

). Obiekt

Request

posia-

da szereg udogodnień, więc za pomocą
metody

add_in_arg

i przeciążonego

operatora

<<=

dodajemy dwa parametry.

Jak łatwo wywnioskować, metodą

set_

return_type

określamy typ wynikowy

tej metody i jest to wartość

void

. Ostatnia

istotna linia z Listingu 6 to

req->invoke()

,

czyli nakazanie wywołania zdalnej
metody. W podobny sposób postąpimy
w przypadku drugiej metody, czyli usta-
lenia treści funkcji ucieczki.

Rysujemy fraktal

Teraz omówimy ostatni element naszego
systemu – funkcję

render_fracal

, w której

następuje proces rysowania fraktala.
W pierwszej kolejności musimy „rozdać”
poszczególnym węzłom kolejne wiersze
do rysowania. Poniższa pętla jest spra-
wiedliwa (choć taka strategia nie zapew-
nia największej wydajności), ponieważ
stara się poszczególnym węzłom przy-
dzielać równą ilość wierszy (zmienna

nn

zawiera numer aktualnego węzła):

for(rows=0;rows<=h;rows++){
r.y=rows; r.from_x=0; r.to_x=w; r.m=0;

reqs.push_back(r); nn++;
if(nn>max_nodes-1) nn=0;
}

Zmienna

r

służy nam do zapamiętania

wartości obiektu wywołania (

Request

)

oraz numeru wiersza aktualnie ryso-
wanego. Zapamiętujemy także wymia-
ry poziome, czyli początek i koniec.
Zawsze są to wartości: zero oraz sze-
rokość wiersza, czyli cały wiersz. Treść
funkcji

begin_render_one_row

jest bliź-

niaczo podobna do

setup_render_size

z Listingu 6. Różni się ostatnią linią:

req->send_deferred();

oraz tym, że

w wywołaniu

set_return_type

jako

typ podajemy własnoręcznie zdefinio-
wany

TypeCode

na samym początku

funkcji

main

naszego klienta. Metoda

send_deferred

zapewnia, że klient po

jej wywołaniu nie będzie czekał, aż
zostanie ona wykonana, lecz przejdzie
do dalszych czynności.

Listing 7 zawiera ostatnią już

pętlę, sprawdzającą, czy żądania
zostały poprawnie obsłużone i czy
można odczytać dane. Pętla prze-
gląda listę żądań

reqs

i spraw-

dza, czy zmienna

m

jest ustawiona

na zero. Jeśli tak, oznacza to, że żąda-
nie zostało już poprawnie obsłużone
i nie trzeba się nim zajmować. W prze-
ciwnym przypadku funkcją

req_is_end

testujemy, czy żądanie zostało już
zakończone i jeśli tak, odbieramy dane
wiersza wywołaniem

get_data

, usta-

wiamy wartość flagi

m

i zwiększamy

zmienną

i

(zawiera ona ilość wierszy

już narysowanych). Cała pętla zakoń-
czy swoje działanie, gdy liczba wierszy
będzie większa od wysokości obrazu
pomniejszonego o jedność (pamiętajmy,
że pierwszy wiersz na numer zero).

Sam proces testowania, czy zada-

nie zostało zakończone, sprowadza się
w funkcji

req_is_end

do polecenia:

req-

>poll_response()

. Sprawdza ono, czy

żądanie zostało obsłużone. Jeśli tak się
stało, to jak wcześniej podałem,

get_data

Listing 5.

Uzyskanie listy wszystkich węzłów

root_ctx

->

list

(

0,

bl, bi

);

max_nodes

=

0

;

while

(

bi

->

next_one

(

b.out

()))

{

CORBA

::

ULong k

;

for

(

k

=

0

;

k

<

b

->

binding_name.length

();

k

++)

{

name

[

0

].

id

=

b

->

binding_name

[

k

].

id

;

name

[

0

].

kind

=

b

->

binding_name

[

k

].

kind

;

nodes.push_back

(

root_ctx

->

resolve

(

name

));

max_nodes

++;

}

}

Listing 6.

Funkcja ustalająca wymiary rysowanego fraktala na odległym obiekcie

void

setup_render_size

(

CORBA

::

Object_var obj, CORBA

::

Long

w, CORBA

::

Long

h

)

{

CORBA

::

Request_var req

=

obj

->

_request

(

„setup_render_size”

);

req

->

add_in_arg

() <<=

w

;

req

->

add_in_arg

() <<=

h

;

req

->

set_return_type

(

CORBA

::

_tc_void

);

req

->

invoke

();

40

maj 2004

klastry obliczeniowe

obiera dane. Kod odbierający dane jest
bardzo krótki:

CORBA::LongSeq row;
req->get_response();
req->return_value() >>= row;
for(int i=0;i<row.length();i++)
*(_row + i) = row[i];

Metoda

get_response

kończy proces

wywołania zdalnej metody i pozwala
„wyciągnąć” z metody

return_value()

dane

reprezentujące

nasz

wiersz.

Następnie przy pomocy prostej pętli
przepisujemy dane ze zmiennej

row

do

odpowiedniego miejsca w tablicy

img

.

Kończąc opis klienta, jeszcze słowo

o tablicy przechowującej poszczegól-
ne wiersze. Tablica

img

to jednowymia-

rowy wektor, w którym są umieszcza-
ne dane wierszy dzięki odpowiedniemu
adresowaniu. Adresowanie może wyda-
wać się „nieco dziwne”, ale pamiętajmy,
że pojedynczy piksel jest opisany trzema
bajtami, więc dlatego podczas adresowa-
nia współrzędne musimy mnożyć przez
trójkę.

Jak rysować fraktale?

Zanim zaczniemy cokolwiek rysować
w naszym rozproszonym systemie,

należy uruchomić usługę nazw. Zastosu-
jemy usługę nazw dostępną w serwerze
OmniORB:

omniNames -start -logdir /tmp

Takie polecenie oznacza, że usługa nazw
założy swój log w katalogu /tmp. Po para-
metrze -start opcjonalnie można umie-
ści numer portu, na którym działa usługa
nazw – domyślnie jest to 2809. Jeśli log
jest już założony, to wystarczy podać
tylko parametr z katalogiem, gdzie ten
log się znajduje:

omniNames -logdir /tmp

Następnym krokiem jest uruchomienie
serwerów

calc_node

, oczywiście na

jak największej ilości różnych kompu-
terów. Poszczególne serwery powin-
ny oczywiście posiadać inną nazwę:

./fc_server.py

wezel_1

. W kodzie

serwera znajduje się także adres usługi
nazw. W plikach znajdujących się na
CD/DVD adres ten odnosi się do kompu-
tera lokalnego, wiec w rzeczywistej sieci
trzeba go koniecznie zmienić.

Gdy serwery zostały juz uruchomio-

ne (do poprawnego działania aplikacji
wystarczy przynajmniej jeden), można

uruchomić klienta. W jego przypadku
także podajemy adres usługi nazw, np.:

ff_clc -ORBInitRef NameService=

S

corbaloc::127.0.0.1:2809/NameService

Klient po zakończonej pracy (miejmy
nadzieję bez kłopotów) powinien pozo-
stawić po sobie plik o nazwie rysu-
nek.pnm, w którym znajduje się rysunek
z fraktalem.

Na zakończenie

Łączny kod źródłowy systemu to zale-
dwie 10 kB. Jak widać, bardzo niskim
nakładem można dość szybko uzyskać
rozproszony system (a można go nawet
nazwać klastrem), zdolny do rysowa-
nia różnego typu fraktali. Stosując tego
rodzaju podejście można bardzo łatwo
rozdzielić każdy problem, pod warun-
kiem, że da się on podzielić na mniejsze
podproblemy, czyli w przypadku rysowa-
nia fraktali – na poszczególne wiersze.

Co jeszcze można unowocześnić

w naszym systemie? Oprócz funkcji itera-
cji, warto by było wprowadzić dodatkową
funkcję kolorującą. Można również wpro-
wadzić znacznie wygodniejszego klienta
opartego np. o biblioteki QT bądź GTK+
– serwer MICO współpracuje przecież
z tymi bibliotekami bez większych pro-
blemów. Zamiast stosowania oddzielnego
serwera CORBY, można także napisać
klienta dla systemu OmniORB – mody-
fikacji nie będzie zbyt wiele. Będą one
głownie dotyczyć definicji typu wiersza,
jaki jest zwracany przez zdalną metodę

render_one_row

.

Zachęcam do modyfikacji przedsta-

wionego systemu, szczególnie te osoby,
które interesują się technologią CORBA.
Na podstawie takiego systemu można
zdobyć wiele cennych doświadczeń.

W Internecie:

– Strona domowa języka Python:

http://www.python.org/

– Strona projektu OmniORB:
http://omniorb.sourceforge.net/
– Strona projektu MICO:
http://www.mico.org/
– Strona nieaktualizowana, ale

zawierająca wiele cennych infor-
macji o fraktalach:

http://spanky.triumf.ca/

– Więcej informacji o fraktalach:

http://www.fractalus.com/ifl/

Listing 7.

Pętla odbierająca wiersze od poszczególnych węzłów

/* cześć I -- odbieranie wyników*/

unsigned char

*

img

=

new unsigned char

[(

w

+

1

)*(

h

+

1

)*

3

];

vector

<

TRequest

>::

iterator reqsIter

;

i

=

0

;

while

(

i

< (

h

-

1

))

{

reqsIter

=

reqs.begin

();

while

(

reqsIter

!=

reqs.end

())

{

r

= *

reqsIter

;

if

(

r.m

==

0

||

req_is_end

(

r.req

)==

1

)

{

get_data

(

r.req,

(

img

+ (

r.y

*

w

*

3

)));

r.m

=

1

;

i

++;

}

reqsIter

++;

}

}

/* część II -- zapis danych do pliku*/

for

(

x

=

0

;

x

<

w

;

x

++)

{

fprintf

(

f_img,

„%d

\n

”,

*(

img

+ ((

y

*

w

*

3

) + (

x

*

3

))));

fprintf

(

f_img,

„%d

\n

”,

*(

img

+ ((

y

*

w

*

3

) + (

x

*

3

)+

1

)));

fprintf

(

f_img,

„%d

\n

”,

*(

img

+ ((

y

*

w

*

3

) + (

x

*

3

)+

2

)));

}

delete

[]

img

;