Hej Mikael,
Du skal have mange tak for de mange gode råd, og for linket. - Jeg har lige
et par spm. mere, som jeg håber jeg må stille dig.
.. - Hvis jeg f.eks. vil foretage et kald fra server1 på maskine/knude1 til
server2 på maskine/knude2, så har jeg forstået det sådan at jeg fra server1
kan lave en naming.lookup for at binde til server2's registry. Når dette er
sket kan jeg kalde, f.eks., sendMessage() metoden, så den også sendes til
brugere på server2.
Hvad jeg ikke ved (jeg har jo ikke prøvet det før) er om dette naming.lookup
fra server1 til server2 medfører at server1 herefter er fast knyttet til
server2 som klient? - Eller om der skal foretages naming.lookup for hver
efterfølgende besked - i så tilfælde er det vel ikke en god løsning (?).
Tager naming.lookup megen tid/degradere ydelsen osv?
Det kunne sikkert gøres smartere med andre løsninger end RMI, men nu har jeg
ligesom bidt mig fast på at finde en løsning med RMI, selvom det mest er
designet til en enkelt server og flere klienter.
Mine spørgsmål er altså:
- kan en remote server knyttes til en anden remote
server v.hj.af naming.lookup, så de forbliver
herefter forbliver bundet sammen i et client/server
forhold og
- er det nødvendigt/uhensigtsmæssigt at kalde
naming.lookup for hver besked der sendes
eller er én gang nok?
Mvh
John
"Mikkel Bundgaard" <mikkelbu@teliamail.dk> wrote in message
news:9h8dp7$jm5$1@sunsite.dk...
> norgaards <norgaards@post.tele.dk> wrote in message
> news:9goom8$cuf$1@news.inet.tele.dk...
> > Hej,
> > Jeg står og skal lave et skoleprojekt. Følgende har jeg ikke
> > været istand til at finde blot en smule information om ude
> > på internettet.
> >
> > Er der nogen der måske kunne give mig et hint, eller som kender
> > et godt eksempel, på hvordan man får flere servere til at samarbejde
> > med RMI. Der findes mange eksempler på hvordan flere klienter og
> > én server arbejder sammen med RMI som middleware, og det
> > er ikke så svært. - Men at skulle få RMI til at fungere med flere
> > servere forvirrer mig. Normalt så genereres der stubs og
> > skeletons med en enkelt server app. Men hvad skal man gøre,
> > når der skal genereres stubs/skeletons, når der er 3 forskellige
> > servere? Bortset fra nogle få ting, så er de ens og kan det samme.
> > Work load skal deles mellem dem, requests omdirigeres til den
> > der har færrest brugere osv.
> >
> > Der er blot tale om et almindeligt chat-program, men det skal
> > være baseret på mere end én server.
> >
> > Der kan vel kun genereres stubs/skeletons på basis af én server
> > source fil? - Hvordan kommer jeg ud over dette problem. Det undrer
> > mig at jeg ikke har kunnet finde noget om flere servere på webbet, da
der
> > tales så meget om skalerbarhed, performance, sikkerhed osv.
> >
> > Jeg håber at en eller anden kender noget til disse ting, og har et hint,
> > eller nogle
> > kommentarer som kan lede mig i den rigtige retning.
> >
> > Med venlig hilsen
> > John
> >
> Hej John
>
> Her er mine ideer til noget som du selv kan gå videre med.
> Den ide, som jeg skitserer, er dog rimelig omfattende (ligesom
> denne tekst er blevet) og nogle steder meget mangelfuldt, så du
> er velkommen til at skære fra og ændre som du selv lyster
.
> Det er sikkert også meget, der kan forbedres/ændres, så det
> skal barer ses som en indledende ide eller brainstorm.
>
> Først nogle kort kommentarer og spørgsmål og derefter en mulig
> (ikke gennemtænkt) måde at implementere dit chat-program på:
>
> * Du kan sondre mellem dine server på deres ip (og evt. en id,
> hvis der er flere servere på en ip). Da en brugerdelen af
> programmet laver lookup (gennem Naming) til en bestemt ip er
> det jo givet hvilken computer/server, hun får fat i.
> * Skal brugere kunne snakke med alle andre eller kun med dem,
> der er på samme server ?
> * Skal brugerne blive på den samme server, eller kan de blive
> "flyttet" til en anden, hvis den bliver for belastet ?
>
> Jeg har nedenstående gået ud fra at alle brugere i systemet kan
> snakke med alle andre. På alle servere "kører" serverdelen af
> programmet og rmiregistry kører også.
>
> Når en bruger logger på systemet, sker det ved at hun kontakter
> en af serverne (er det egentlig ikke peers, da ingen af dem
> bestemmer over de andre). Da alle server kender antallet af
> brugere på de andre server (se længere nede under workload)
> finder serveren den mindst belastede og returnere adressen på
> den til brugeren, som der så derefter kun arbejder gennem denne.
> Denne server skal så løbende opdatere sine tekstkøer (de
> beskeder som brugere sætter ind i systemet) med de andre servere.
> Derved får alle brugere alle beskeder (hvis man ønsker dette).
> Når brugeren så er færdig med chatten og logger fra, skal
> antallet af brugere tælles en ned.
>
> workload
> Du ønsker at workload skal deles og der er to måder (mindst),
> hvorpå dette kan løses. Enten snakker serverne samme f.eks.
> hvert minut, så alle ved hvem, der er mindst belastet. Eller også
> udspørger den server, som man logger sig på, de andre om hvor
> belastede de er.
>
> metoder på serveren
> Da alle servere principielt skal kunne "alt" er der her nogle af
> de metoder som de alle skal indeholde:
> * En metode, der på en eller anden måde returnere adressen
> på den server, der er mindst belastet.
> * En metode, der returnere antallet af brugere på serveren.
> * Metoder, der hjælper med til at distribuere beskeder i systemet.
> * Find selv på flere
.
>
> Jeg håber du kan bruge noget af alt denne rodede information.
> Måske skulle du prøve at kigge på om der ikke var nogle
> peer-to-peer implementeringer, der bruger rmi. Disse vil sikkert
> kunne give dig noget inspiration
>
> PS. Du kan evt. kigge på min hjemmeside under "SubSpace"
> (findes til højre), hvor mit seneste projekt ligger. Dette projekt
> er en peer-to-peer implementering af Suns JavaSpaces.
> Dette projekt er ikke helt, hvad du ønsker, men du kan måske
> få ideer fra designet/implementeringen.
> --
> Mvh.
> Mikkel Bundgaard
> RUC Datalogi
>
http://officehelp.gone.dk
>