chord client aufgabe

Moderator: Peer-to-peer und Grid Computing

Benutzeravatar
aiQon
Windoof-User
Windoof-User
Beiträge: 32
Registriert: 9. Dez 2010 18:23
Wohnort: Darmstadt

chord client aufgabe

Beitrag von aiQon »

Hi,
I have a question towards the bootstrapping process:
the slides tell:

CS_INITIAL_JOIN = 1
– Payload: identfier (8 Byte)
– Reply: NONE
– Triggers the peer to join the overlay
•Finding its positon in the Chord identfier space
•Initating finger table and successor/predecessor links
•Notfying predecessor / successor

why does the command server supply an identifier? the node chooses it by itself, doesnt it (by hashing its ip and cutting to meet the supplied identifier space)

as far as i understood the newly joining node needs a different node which is already in the chord ring or the info to form a new one?

thanks for enlightening me

cheers, stas
weeks of coding can save hours of planing

Benutzeravatar
BadTaste
Endlosschleifenbastler
Endlosschleifenbastler
Beiträge: 181
Registriert: 18. Apr 2005 16:40
Wohnort: Darmstadt
Kontaktdaten:

Re: chord client aufgabe

Beitrag von BadTaste »

Hi,

the command server supplies the identifier to ensure that there are no collisions in case the identifier space is rather small, e.g., 10 nodes in a 4-bit identifier space.

The joining node can request such a bootstrap node from the file server using the FS_HELLO message.
The file then replies with the address (IP + port) of a node that has already joined the network.
In case the requesting node is the first one, the answer simply contains byte[]{0, 0, 0, 0, 0, 0, 0, 0} to indicate that the requesting node is the first one.

Hope that answers your questions.

greets
benni

Benutzeravatar
aiQon
Windoof-User
Windoof-User
Beiträge: 32
Registriert: 9. Dez 2010 18:23
Wohnort: Darmstadt

Re: chord client aufgabe

Beitrag von aiQon »

is the uuid and the message counter transmitted with big or with little endian?
weeks of coding can save hours of planing

Benutzeravatar
BadTaste
Endlosschleifenbastler
Endlosschleifenbastler
Beiträge: 181
Registriert: 18. Apr 2005 16:40
Wohnort: Darmstadt
Kontaktdaten:

Re: chord client aufgabe

Beitrag von BadTaste »

Both, like all numbers, are transmitted as big-endian, i.e., the number 3 would be transmitted as 00 0....0 00 11 (in Bit).
A long with value 259 would be transmitted as 00 00 00 13 (in Byte).

Benutzeravatar
aiQon
Windoof-User
Windoof-User
Beiträge: 32
Registriert: 9. Dez 2010 18:23
Wohnort: Darmstadt

Re: chord client aufgabe

Beitrag von aiQon »

for the 259 part, dont u mean 00 00 00 00 00 00 01 03 (in its hex representation in big endian)?
weeks of coding can save hours of planing

Benutzeravatar
BadTaste
Endlosschleifenbastler
Endlosschleifenbastler
Beiträge: 181
Registriert: 18. Apr 2005 16:40
Wohnort: Darmstadt
Kontaktdaten:

Re: chord client aufgabe

Beitrag von BadTaste »

No, i mean the bytes that you get when transmitting an 8-Byte long value.

Benutzeravatar
RT89
Erstie
Erstie
Beiträge: 12
Registriert: 8. Nov 2010 16:44

Re: chord client aufgabe

Beitrag von RT89 »

Hi!

I would like to know if the peer should be able to handle multiple connections at one time. E.g. when the peer is communicating with another peer and receiving a file, should it still accept commands from the command server? Because then, there would have to be multiple ports used for a peer...
aiQon hat geschrieben:for the 259 part, dont u mean 00 00 00 00 00 00 01 03 (in its hex representation in big endian)?
P.S.: I think aiQon is right concerning the byte representation of 259 as a long value represented as hex bytes in big endian. Could you check on your answer again?

thanks in advance,
rt

Benutzeravatar
BadTaste
Endlosschleifenbastler
Endlosschleifenbastler
Beiträge: 181
Registriert: 18. Apr 2005 16:40
Wohnort: Darmstadt
Kontaktdaten:

Re: chord client aufgabe

Beitrag von BadTaste »

RT89 hat geschrieben:I would like to know if the peer should be able to handle multiple connections at one time. E.g. when the peer is communicating with another peer and receiving a file, should it still accept commands from the command server? Because then, there would have to be multiple ports used for a peer...
Since we are using asynchronous communication, there is no need for additional ports.
After getting a message, the client simply initiates the actions that are induced by the received message.
After that, it simply gets the next message that was was sent to the client, independent of when it was sent.
RT89 hat geschrieben:P.S.: I think aiQon is right concerning the byte representation of 259 as a long value represented as hex bytes in big endian. Could you check on your answer again?
Yes, he ist right when saying, that 00 00 00 00 00 00 01 03 is the hex-representation for 259.
All I was saying that I was not writing down the hex-representation of 259 but the list of bytes resulting in a transmission of 259 as a long, i.e., an 8 Byte array.

Benutzeravatar
Maeher
Sonntagsinformatiker
Sonntagsinformatiker
Beiträge: 282
Registriert: 14. Okt 2007 23:02
Kontaktdaten:

Re: chord client aufgabe

Beitrag von Maeher »

In der Übung wurde gesagt, dass das ganze über TCP bzw. in Java über die Socket Klasse ablaufen würde. Aber im Moment hört sich das ganze für mich nach UDP, (bzw der DatagramSocket in Java) an.
Denn mit TCP würde ja in jedem fall jede Verbindung an einen neuen Port gebunden.

Benutzeravatar
aiQon
Windoof-User
Windoof-User
Beiträge: 32
Registriert: 9. Dez 2010 18:23
Wohnort: Darmstadt

Re: chord client aufgabe

Beitrag von aiQon »

jave oder nicht, wenn du tcp nimmst und auf einem socket mit accept() auf eine verbindung wartest (das ist ein OS call und blockiert deinen prozess) dann bekommst du nach erfolgreichem akzeptieren einen neuen socket (neuer port auf deinem rechner) auf dem du die verbindung abarbeiten kannst. der ursprüngliche port, auf dem du vorher mit accept() gelauscht hast, ist danach weiterhin "frei" und kann zB in einer schleife wieder blockieren.

an dieser stelle kannst du dann mit diversen "betriebsystemtricks" arbeiten, zB non-blocking I/O, multiplexern (wie zB select) oder multi-threaded. Das ist dann deinem grad an masuchismus überlassen.

was ich mich frage ist: bekommen wir nicht iwann noch implementierungen des CS, FS und MS ? Die ganze Zeit mit netcat zu arbeiten ist auf dauer langwierig und fehleranfällig :<
weeks of coding can save hours of planing

Benutzeravatar
Maeher
Sonntagsinformatiker
Sonntagsinformatiker
Beiträge: 282
Registriert: 14. Okt 2007 23:02
Kontaktdaten:

Re: chord client aufgabe

Beitrag von Maeher »

Since we are using asynchronous communication, there is no need for additional ports.
Darum geht es.

Wenn wir TCP verwenden, verwenden wir definitiv mehr als einen Port.
Es macht definitiv einen großen Unterschied, ob ich eine Anfrage per TCP schicke und über die gleiche TCP-Verbindung auch meine Antwort erwarte, oder ob das ganze Verbindungslos passiert.

Und im Moment hört sich das ganze ziemlich verbindungslos an.

Benutzeravatar
aiQon
Windoof-User
Windoof-User
Beiträge: 32
Registriert: 9. Dez 2010 18:23
Wohnort: Darmstadt

Re: chord client aufgabe

Beitrag von aiQon »

Maeher hat geschrieben: Es macht definitiv einen großen Unterschied, ob ich eine Anfrage per TCP schicke und über die gleiche TCP-Verbindung auch meine Antwort erwarte, oder ob das ganze Verbindungslos passiert.
wenn du ein p_find_successor schickst, wird der request rekursiv weitergeleitet aber es gibt laut folien nur eine antwort, sprich der eigentliche successor des requesters startet eine kommunikation mit dem requester und schickt ihm die antwort. soll heißen, der request wird über einen anderen socket verschickt als die antwort angenommen wird, imho...

aber da sollte benni wohl was zu sagen >>
weeks of coding can save hours of planing

Benutzeravatar
BadTaste
Endlosschleifenbastler
Endlosschleifenbastler
Beiträge: 181
Registriert: 18. Apr 2005 16:40
Wohnort: Darmstadt
Kontaktdaten:

Re: chord client aufgabe

Beitrag von BadTaste »

Hi,
wie aiQon es beschrieben hat, funktioniert es in der tat.
Wir verwenden die Klassen java.net.Socket und java.net.ServerSocket zum Senden und Empfangen der Nachrichten.
Diese kapseln TCP, die Verwendung weiterer Ports wird dabei vom OS bewerkstelligt.
Daher benötigt man bei der Verwendung dieser Klasse auch nur den einen Port.
Obwohl diese Klassen bidirektionalen Datenaustausch unterstützen, verwenden wir nur unidirektionale Nachrichten, d.h. eine Verbindungs wird nach dem Lesen gleich wieder geschlossen und die Antworten über eine neue Verbindung gesendet.

Unsere Server Implementierung sollte voraussichtlich bis morgen verfügbar sein.

Antworten

Zurück zu „Peer-to-Peer und Grid Computing“