JXTA

JXTA
Utvecklare Öppen källkod (gemenskapsutvecklad)
Stabil frisättning
2.7 / Mars 2011
Operativ system Cross-plattform
Plattform Java Platform, Standard Edition , Java Platform, Micro Edition , C / C++ / Microsoft .NET
Typ Peer-to-peer
Licens Baserat på Apache-licensen
Hemsida jxse .kenai .com (ounderhållen)

JXTA ( Juxtapose ) var en peer-to-peer- protokollspecifikation med öppen källkod som startade av Sun Microsystems 2001. JXTA- protokollen definierades som en uppsättning XML -meddelanden som gör att alla enheter som är anslutna till ett nätverk kan utbyta meddelanden och samarbeta oberoende av underliggande nätverkstopologi .

Eftersom JXTA baserades på en uppsättning öppna XML-protokoll, kunde den implementeras i vilket modernt datorspråk som helst. Implementeringar utvecklades för Java SE , C / C++ , C# och Java ME . C # -versionen använde de ursprungliga C++ / C -bindningarna och var inte en fullständig omimplementering i sig.

JXTA-kamrater skapar ett virtuellt överläggsnätverk som gör att en peer kan interagera med andra peers även när några av peers och resurser är bakom brandväggar och NAT:er eller använder olika nätverkstransporter. Dessutom identifieras varje resurs av ett unikt ID, en 160 bitars SHA-1 URN i Java-bindningen, så att en peer kan ändra sin lokaliseringsadress samtidigt som den behåller ett konstant identifieringsnummer.

Status

"I november 2010 tillkännagav Oracle officiellt sitt tillbakadragande från JXTA-projekten". Från och med augusti 2011 har JXTA-projektet ännu inte fortsatt eller på annat sätt meddelats för att behålla verksamheten, varken beslut fattades om sammansättningen av dess styrelse eller ett svar från Oracle angående en väntande begäran om att flytta källkoden till Apache-licensversionen 2.

Protokoll i JXTA

  • Peer Resolver Protocol
  • Peer Information Protocol
  • Rendezvous Protocol
  • Peer Membership Protocol
  • Rörbindningsprotokoll
  • Endpoint Routing Protocol

Kategorier av kamrater

JXTA definierar två huvudkategorier av kamrater: kantkamrater och superkamrater . Super-peers kan ytterligare delas in i rendezvous och relay peers . Varje peer har en väldefinierad roll i JXTA peer-to-peer-modellen.

  • Edge -peers definieras vanligtvis som peers som har transient nätverksanslutning med låg bandbredd . De bor vanligtvis på gränsen till Internet, gömda bakom företagets brandväggar eller kommer åt nätverket via icke-dedikerade anslutningar.
  • En Rendezvous-peer är en peer för specialändamål som ansvarar för att koordinera peers i JXTA-nätverket och ger det nödvändiga utrymmet för meddelandeförmedling. Om peers finns i olika subnät bör nätverket ha minst en Rendezvous-peer.
  • En Relay peer tillåter kamrater som finns bakom brandväggar eller NAT-system att delta i JXTA-nätverket. Detta görs med hjälp av ett protokoll som kan passera brandväggen, som till exempel HTTP .

Vilken peer som helst i ett JXTA-nätverk kan vara en mötesplats eller relä så snart de har nödvändiga referenser eller krav på nätverk/lagring/minne/CPU.

Annonser

En annons är ett XML-dokument som beskriver alla resurser i ett P2P-nätverk (kamrater, grupper, pipes, tjänster, etc.). Kommunikationen i JXTA kan ses som utbyte av en eller flera annonser via nätverket.

Rör

Pipes är en virtuell kommunikationskanal som används av JXTA för att utbyta meddelanden och data. Rör är asynkrona, opålitliga och enkelriktade. Det finns i princip tre typer av rör:

Kamratgrupper

En kamratgrupp ger ett utrymme för spridning av meddelanden och en logisk klustring av kamrater. I JXTA är varje peer medlem av en standardgrupp, NetPeerGroup, men en given peer kan vara medlem i många undergrupper samtidigt. En kamrat kan spela olika roller i olika grupper; det kan fungera som en kantkamrat i en grupp, men ett möte i en annan.

Varje grupp bör ha minst en rendezvous-peer och det är inte möjligt att skicka meddelanden mellan två grupper.

Rendezvous nätverk

Rendezvous-peers har en optimerad routingmekanism som möjliggör en effektiv spridning av meddelanden som pushas av kant-peers som är anslutna till dem. Detta uppnås genom användning av ett löst konsekvent nätverk.

Varje Rendezvous-peer upprätthåller en Rendezvous Peer View (RPV), en lista över kända rendezvous-kamrater sorterade efter Peer-ID. Det finns ingen mekanism för att framtvinga konsistensen av alla RPV:er över JXTA-nätverket, så en given RPV kan ha en tillfällig eller permanent inkonsekvent bild av de andra mötesplatserna. Så snart det finns en låg churn rate , det vill säga ett stabilt nätverk där peers inte går med eller lämnar för ofta, kommer RPV-listan för varje peer att konvergera när varje rendezvous peer utbyter en slumpmässig delmängd av sin RPV med andra rendezvous peers då och då.

När en kantkollega publicerar en annons, skjuts indexet för denna annons till mötesplatsen genom ett system som kallas Shared Resource Distributed Index (SRDI). Efter det tillämpar mötesplatsen en Distributed Hash Table) så att den kan vidarebefordra indexet till en annan peer i RPV-listan. För replikeringsändamål kommer den att skicka detta index till grannarna till den valda mötesplatsen i RPV-listan.

Uppslagsprocessen kräver användning av samma DHT-funktion för att upptäcka mötesplatsen som är ansvarig för att lagra det indexet. När rendezvous-peeren har nåtts kommer den att vidarebefordra frågan till edge-peeren som publicerade annonsen och denna peer kommer att kontakta den peer som utfärdar frågan.

Om DHT-funktionen inte kan hitta en peer som är ansvarig för annonsen kommer frågan vidarebefordras upp och ner i RPV-listan tills en matchning hittas, frågan avbryts eller den når gränserna för RPV-listan. Denna process kallas random walk.

Se även

externa länkar