«« ( Date ) »» // «« ( Thread ) »» // drs - 2007

Re: Re: Za asistenta: nekoliko pitanja u vezi domaceg

by Zaharije Radivojevic
sreda, 23. maj 2007 - 17:02.


Postovani,

U nastavku su odgovori na Vasa pitanja.

> kako biste nam savetovali da najlakse na kor programu uradimo unos
> maske posto je u pitanju komplikovana stvar za gui?
Za ovo su dovoljna 4 polja. Gorlji elvi i desni ugao maske i donji desni
ugao slike. Do ovih parametara se moze doci ili tako sto gledate
koordinete na panelu na koji kacite ili korisnik lupi neke koordinate a vi
onda pre slike iscrtare marker.

> Da napravimo par patterna, npr sviPikseli, dijagonalniPikseli itd ili da
> to bude neki pravougaonik na samoj slici i gotovo?
Mislim da se trazi da maska bude kvadrat.

> na osnovu prethodnog maila, kor. program treba da bira funkciju, tj
> server.
Mozete da stavite i da korisnik unosi neko ime funkcije koje cete Vi onda
da prosledjujete serveru, koji ce to da prosledi klijentima kao onaj niz
objekata, koji ce ona metoda za obradu slike da koristi (verovatno ce to
plje da se ignorise).

> To znaci da je 1server=1tip posla, tj da radne stanice koje
> su zakacene na njega imaju istu ImageProcessing klasu, jel tako (nadam
> se da ne moramo ovo da proveravamo prilikom konekcije radne stanice)?
Mislim da trenutno ne morate da vodite racuna o tome sta radi
ImageProcessing klasa, i kako je ona distribuirana po radnim stanicama.

> Kako mogu kor. programi da znaju koji su serveri aktivni i njihove
> adrese/portove/funkcije?
Pa neko im kaze. Ovo polje ce ili ucitati korisnicki program kroz GUI ili
ete ga postaviti kao parametar konfiguracie. Nije dobro da fiksirate
vrednosti tako da svaki put kada nesto promenite (ima racunara,
IP) korisnik mora da ponovo kompailira program.

> radna stanica salje sinhronizacionu poruku kada je zavrsila posao, jel
> tako?
Ovo je generalna prica kako bi to trebalo da radi, a kako cete Vi to da
realizujete to je druga stvar.

> U postavci pise da se ceka da se ispuni neki uslov koji je vezan
> za parametre,
Ove uslove Vi definisete.
> a da se posao deli izmedju radnih stanica, ali tako podeljeni poslovi se
> spajaju samo na serveru, je li tako?
Ovo je opet implementacioni detalj. Radne stanice mogu i medjusobno da
razmenjuju poruke, ali morate da vodite racuna o broj poruka kroz mrezu.

> Znaci moze se zakljuciti da su parametri nama potrebni samo za
> identifikaciju podposla da bi server znao kako da ih spoji na kraju
> iteracije, nije potrebno slati sledece parametre koji su me zbunili: "sa
> kojim poslovima komunicira i KADA(?) je potrebno ostvariti komun. sa
> drugim poslovima"?
Ovo ipak spada u ono sto cete Vi isprogramirati. Opet ponavljam ono sto je
data je generalna prica koja kaze kako program treba da radi. Hocete bas
tako da realizujete ili ce te mozda malo optimizovati to je Vasa stvar.

> I na kraju bih da mi samo potvrdite naredni scenario koji ce verovatno
> da testirate kada predajemo: server ce, u slucaju da je neka radna
> stanica neaktivna nakon x sekundi, da posalje nekoj drugoj radnoj
> stanici RSX taj posao koja je verovatno vec poslala sinhr. poruku jer
> je raniji posao zavrsila. I sve te radne stanice koje su svoj posao
> obavile cekati da RSX ponovo posalje sinh. poruku serveru, po drugi
> put, pa da zatim sinh. poruku posalje server svim radnim stanicama -
> tek tada mogu da posalju gotove podposlove serveru! Jel tako
> zamisljeno?
Slanje sinhronizacionih poruka moze da obavlja u paraleli sa slanjem
podataka serveru. Na ovaj nacin povecavate konkurentnost programa koji
pisete.
Na odbrani cete prikazati scenario u kome sve lepo raid. Onda cete ubiti,
u vreme izvsavanja neku stanicu, i sistem treba i dalje lepo da radi. Kako
ce se raditi balansiranje i sinhronizacija to je vec projektantska odluka.

Pozdrav
Zaharije