Übung 3

Transcrição

Übung 3

Übungen zu „Rechnerkommunikation“
Wintersemester 2010/2011
Übung 3
Mykola Protsenko, Jürgen Eckert
PD. Dr.-Ing. Falko Dressler
Friedrich-Alexander
d h l
d Universität Erlangen-Nürnberg
l
b
Informatik 7 (Rechnernetze und Kommunikationssysteme)
Rechnerkommunikation, Übung 3
1
Anwendungsschicht
 Das Web: Hypertext Transfer Protocol (HTTP)




HTML
Conditional GET
Authentifizierung
Cookies
 File Transfer Protocol (FTP)
E
E-Mail
Mail
 SMTP
 Nachrichtenformat
 Zugriffsprotokolle
 Socket-Programmierung (UDP)
 Peer-to-Peer
P
t P
S
Systeme
t
2
HTTP
 Ablauf
 Benutzer gibt Uniform Resource
Locator (URL) in Web-Browser
ein
 URL enthält Host-Namen eines
PC mit
it
Web-Servers und den Pfad zu
Browser
(z.B. Firefox)
einem Objekt (Datei) dort
 Web-Browser
Web Browser stellt Anfrage an
Web-Server für dieses Objekt
 Web-Server liefert Objekt an
Web Browser zurück
Web-Browser
 Web-Browser stellt Objekt in für
den Benutzer lesbarer Form dar
Server
mit
Apache
Webserver
Mac mit
Browser
(z.B. Safari)
3
HTTP
 URL
http://www.someschool.edu:80/someDept/pic.gif
Dienst
Hostname
Portnr.
Pfad zum Objekt
 nicht alle Teile müssen dabei sein
 Nachrichtentypen in HTTP
 Anfragenachrichten
 Antwortnachrichten
 beide beinhalten nur ASCII-Zeichen und sind daher lesbar
Rechnerkommunikation, Anwendungsschicht
4
GET /somedir/page.html HTTP/1.1
Host: www.someschool.edu
User-agent: Mozilla/4.0
Connection: close
Accept-language:fr
HTTP: Format der
Anfragenachrichten
(extra carriage return, line feed)
Anfragezeile
method
sp
URL
sp
version
header field name: sp
value
cr lf
header field name: sp
value
cr lf
Kopfzeilen
p
Leerzeile
p
Rumpf
cr lf
cr lf
HTTP
 Aufbau von Web-Seiten
 Basis
Basis-Seite
Seite in Hypertext Markup-Language
Markup Language (HTML)
 eingebettete Objekte (Bilder, Video, Audio, Code, …)
 Referenzen auf andere Web-Seiten
<html>
<head><title>AMALGAMATED WIDGET, INC.</title></head>
<body><h1>Welcome to AWI`s Home Page</h1>
<img src=
src="http:www
http:www.widget.com/images/logo.gif
widget com/images/logo gif" ALT=
ALT="AWI
AWI Logo"><br>
Logo ><br>
We are so happy that you have chosen to visit <b>Amalgamated Widget‘s</b>
home page. We hope <i>you</i> will find all the information you need here.
<p>Below we have links to information about our many fine products. You
can order electronically (by WWW), by telephone, or by FAX.</p>
<hr>
<h2>Product information</h2>
<ul>
<li><a href="http://widget.com/products/big">Big widgets</a>
<li><a href="http://widget.com/products/little">Little widgets</a>
</ul>
<h2>Telephone numbers</h2>
<ul>
<li>By telephone: 1-800-WIDGETS
<li>By fax: 1-415-765-4321
</ul>
</body>
</ht l>
</html>
Welcome to AWI‘s Home Page
We are so happy that you have chosen to visit Amalgamated Widget‘s home
page. We hope you will find all the information you need here.
Below we have links to inform about our many fine products. You can order
electronically (by WWW), by telephone, or by FAX.
Product Information
• Big widgets
• Little widgets
Telephone numbers
• 1-800-WIDGETS
• 1-415-765-4321
6
HTTP: Aufbau von Web-Seiten
 Häufige HTML-Tags (weiter Infos unter: http://de.selfhtml.org)
T
Tag
D
Description
i ti
<html> … </html>
Declares the Web page to be written in HTML
<head> … </head>
Delimits the page's head
<title> … </title>
Defines the title (not displayed on the page)
<body> … </body>
Delimits the page's body
<h n> … </h n>
Delimits a level n heading
<b> … </b>
Set … in boldface
<i> … </i>
Set … in italics
<center> … </center>
Center … on the page horizontally
<ul>
u … </ul>
/u
Brackets
ac ets an
a unordered
u o de ed (bulleted)
(bu eted) list
st
<ol> … </ol>
Brackets a numbered list
<li>
Starts a list item (there is no </li>)
<br>
Forces a line break here
<p>
Starts a paragraph
<hr>
Inserts a horizontal rule
<img
g src="…">
Displays
p y an image
g here
<a href="…"> … </a>
Defines a hyperlink
7
HTTP: Dynamische Inhalte
 Formular
 Benutzer kann Daten in Browser eingeben
<html>
<head><title>Test Anmelde formular</title></head>
<body>
<form method="post" action="/path/to/anmeldung" enctype="multipart/form-data">
<table border=0>
<tr><td align=right>Name:</td><td><input type="text" name="Name" size="30"/></td></tr>
<tr><td align=right>Matrikelnummer:</td><td><input type="text" name="Matnr" size="30"/></td></tr>
<tr><td align=right>Schein:</td><td><select name="Schein">
<option value="kein Schein">kein Schein</option>
<option value="benoteter Schein">benoteter Schein</option>
<option value="unbenoteter Schein">unbenoteter Schein</option>
</select></td></tr>
<tr><td></td><td><input type="submit" name="Absenden" value="Absenden" /></td></tr>
</table>
</form>
</body>
</html>
 Browser liefert Typ/Wert-Paare an Server:
- Mit method=„get“:
/path/to/anmeldung?Name=John+Doe&Matnr=0123456&Schein=b
enoteter+Schein&Absenden=Absenden
- Mit method=„post“: Parameter in der Kopfzeile von HTTP
8
HTTP: Conditional GET
 Ziel: Objekt nicht neu übertragen,
g , wenn der Client
aktuelle Version im Cache hat
 Cli
Client:
t übergibt
üb ibt das
d Datum
D t
der Kopie im Cache
Client
Server
HTTP request msg
If-modified-since:
<date>
HTTP response
 If-modified-since: <date>
HTTP/1.0
304 Not
N t Modified
M difi d
 Server: Antwort enthält kein
Objekt wenn die Kopie im
Objekt,
Cache aktuell ist:
HTTP request msg
 HTTP/1.0 304 Not Modified
If-modified-since:
<date>
HTTP response
 Häufig bei Web Caches,
Proxies
HTTP/1.0 200 OK
<data>
Objekt
im
C h
Cache
aktuell
Objekt
im
Cache
nicht
aktuell
9
HTTP: Authentifizierung
 Ziel: Zugriffskontrolle für Objekte
auf dem Server
 HTTP ist zustandslos, daher muss
die Autorisierung in jedem Request
erfolgen
f l
 Autorisierung üblicherweise mittels
B
Benutzername
t
und
dP
Passwortt
 Kopfzeile im Request nötig:
authorization
 Fehlt diese Kopfzeile,
Kopfzeile sendet der Server
keine Daten, sondern in einer Kopfzeile
der Antwort: WWW-Authenticate
 Ü
Übliche Browser speichern
Benutzernamen und Passwort, so
dass die Daten nur einmal
eingegeben
i
b werden
d müssen
ü
Server
Client
Üblicher HTTP Request
401: Autorisierungsanfr.
WWW-Authenticate:
Authorization: Zeile
Übliche HTTP Antwort
Authorization: Zeile
10
HTTP: Cookies
Client
 Ziel: HTTP eigentlich zustandslos,
trotzdem Zustand für Client merken
 Server sendet “Cookie” in der
Antwort an den Client
 Set-cookie: 1678453
 Client speichert Cookie
(in spezieller Datei)
 In weiteren Anfragen überträgt der
Client das Cookie mit:
 cookie: 1678453
 Server gleicht das präsentierte
Cookie mit Informationen auf dem
Server ab:
 Authentifizierung
 Benutzereinstellungen, vorangegangene
Auswahl (z.B. Sprache)
 Zielgruppengerichtete Werbung
((Verfolgende
g
Cookies: ermöglichen
g
Servern, Informationen über den Besuch
anderer Server zu erhalten)
Server
q
Übliche HTTP Antwort +
Set-cookie: #
Üblicher HTTP Request +
cookie: #
Üblicher HTTP Request +
cookie: #
Cookiespezifische
Aktion
Cookiespezifische
Akti
Aktion
11
Anwendungsschicht
 Conditional GET
 Cookies
 E-Mail
 SMTP
 Peer-to-Peer Systeme
12
FTP
 File Transfer Protocol
 Übertragung von Dateien zwischen Hosts
 eine TCP-Verbindung (Port 21) zur Steuerung
 lesbare Kommandos: USER username, PASS password, LIST, RETR
fil
filename,
STOR filename,
fil
…
 jeweils eine TCP-Verbindung (Port 20) zur Übertragung einer Datei
 „out-of-band-control“
13
FTP: Separate Steuer- und Datenverbindungen
 FTP-Client kontaktiert FTPServer auf Port 21 mittels TCP
(S
(Steuerverbindung)
bi d
)
 Authentifizierung über die
Steuerverbindung
 Client kann Inhalt des
entfernten Verzeichnisses über
g ansehen
die Steuerverbindung
 Sobald der Server einen Befehl
zur Dateiübertragung erhält,
baut er mittels TCP eine
Datenverbindung zum Client
auf (hier: Active Mode)
 Nach der Dateiübertragung
schließt der Server die
Datenverbindung.
TCP Steuerverbindung
Port 21
FTPClient
TCP Datenverbindung
g
Port 20
FTPServer
 Server öffnet weitere
Datenverbindungen für weitere
Datenübertragungen.
g g
 Separate Steuerverbindung:
“Out-of-Band”
 FTP
FTP-Server
Server speichert
Zustandsinformationen:
aktuelles Verzeichnis,
vorangegangene Authentifizierung
14
FTP: Befehle und Rückgabewerte
 Beispiele für Befehle:
 als ASCII
ASCII-Text
Text über die
Steuerverbindung gesendet
 USER username
 PASS password
 LIST liefert eine Liste von
Dateien im aktuellen
Verzeichnis
 RETR filename lädt eine
Datei vom Server
 STOR filename speichert
i h t
eine Datei auf dem Server
 Beispiele für Rückgabewerte:
 Statuscode und textuelle
Meldung (wie bei HTTP)
 331 Username OK,
password required
p
q
 125 data connection
already open; transfer
starting
 425 Can’t open data
connection
 452 Error writing file
15
FTP: Active Mode vs. Passive Mode
 Active Mode
 Client baut eine TCP-Verbindung
von einem beliebigen
unprivilegierten TCP-Port N zu
Port 21 des Servers auf
(Steuerverbindung)
 Vor Dateiübertragung sendet
Client den Befehl
PORT N+1
an den Server und wartet auf
TCP-Verbindungen auf Port N+1
 Server baut eine TCPVerbindung von seinem lokalen
Port 20 zu Port N+1 des Clients
auf (Datenverbindung)
 Problem:
P bl
Fi
Firewall
ll muss
Verbindungen vom Server zu
Port N+1 zulassen
 Passive Mode
von einem beliebigen
unprivilegierten TCP-Port N zu
Port 21 des Servers auf
(Steuerverbindung)
 Vor Dateiübertragung sendet
Client den Befehl
S
PASV
an den Server. Der Server
wartet auf einem beliebigen
unprivilegierten Port P auf
eingehende
i
h d Verbindungen
V bi d
vom
Client und teilt dem Client im
Rückgabewert des Befehls
diesen Port P mit.
von seinem lokalen Port N+1 zu
Port P des Servers auf
(Datenverbindung).
16
Anwendungsschicht




HTML
Conditional GET
Authentifizierung
Cookies
E
E-Mail
Mail
 SMTP
 Peer-to-Peer
P
t P
S
Systeme
t
17
E-Mail
 Simple Mail Transfer Protocol (SMTP)
 Nachrichten im ASCII
ASCII-Format
Format, Kopf,
Kopf Rumpf
 andere Daten (Word-Dateien u.ä.) werden in ASCII umgewandelt
angehängt: MIME
 Versenden
V
d mit
it SMTP über
üb TCP (lesbar)
(l b )
 Abholen mit POP3, IMAP, HTTP (lesbar)
18
E-Mail
Warteschlange für
ausgehende Nachrichten
Benutzer-Mailbox
Drei wesentliche Komponenten:
 Mail User Agents (MUA)
 Mail-Server
 Simple Mail Transfer Protocol:
SMTP
Mail User Agent
 Mail-Client
Mail Client
 zum Verfassen, Editieren und Lesen
von Nachrichten
 z.B.
B Thunderbird,
Th d bi d Outlook,
O tl k mutt,
tt
Evolution
 Ausgehende und eingehende
Nachrichten auf Server gespeichert
MUA
MUA
MailServer
SMTP
MailServer
SMTP
SMTP
MUA
MUA
MailServer
MUA
MUA
19
E-Mail: Mail-Server
Mail-Server
 Mailbox enthält (ungelesene)
eingegangene Nachrichten für
Benutzer (Briefkasten)
 Warteschlange
W t hl
für
fü ausgehende
h d
(zu sendende) Nachrichten
 SMTP-Protokoll zwischen MailServern zum
Nachrichtenaustausch
 Client: sendender Mail-Server
Mail Server
 Server: empfangender Mail-Server
Warteschlange für
ausgehende Nachrichten
Benutzer-Mailbox
MUA
MUA
MailServer
SMTP
MailServer
SMTP
SMTP
MUA
MUA
MailServer
MUA
MUA
20
Weiteres zu SMTP
 SMTP verwendet persistente
Verbindungen
g
 für SMTP müssen die
Nachrichten (Header & Body)
als 7-bit-ASCII-Text vorliegen
 Einige Zeichenketten (z.B.
CRLF.CRLF) sind in
Nachrichten nicht erlaubt.
Daher müssen Nachrichten
codiert werden ((üblicherweise
Base-64 oder Quoted
Printable)
 Der SMTP-Server nutzt
CRLF.CRLF zum Erkennen
des Endes einer Nachricht
Vergleich mit HTTP
 HTTP: pull (d.h.
(d h Empfänger
fordert an)
 SMTP: push (d.h. Sender sendet
unaufgefordert an Server)
 beide verwenden Interaktion mit
ASCII-Befehlen und Antworten
sowie Statuscodes
 HTTP: Jedes Objekt wird in einer
eigenen
i
Antwortnachricht
A t
t
h i ht
gekapselt
 SMTP: Mehrere Objekte einer
Nachricht werden in einer so
genannten Multipart-Nachricht
versendet
21
Mail-Nachrichtenformat
 SMTP: Protokoll zum
Austausch von Nachrichten
 RFC 822: Standard für das
Nachrichtenformat:
 Kopfzeilen
Kopfzeilen, z.B.
zB
- To: (Empfänger)
- From: (Absender)
- Subject: (Betreff)
 unterscheidet sich von SMTPBefehlen!
Header
Leerzeile
l
Body
 Body
B d
 Die „Nachricht“ selbst, reiner
ASCII-Text
22
Nachrichtenformat: Multimedia-Erweiterungen
 MIME: Multipurpose Internet Mail Extensions, RFC 2045
 Zusätzliche Kopfzeilen im Nachrichtenkopf bestimmen den MIME
Content Type (Art/Typ des Inhalts)
MIME-Version
Codierungsmethode
für Daten
Multimedia-Datentyp,
Unterart,
Parameterfestlegung
Codierte Daten
From: [email protected]
To: [email protected]
Subject: Picture of yummy crepe.
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Type: image/jpeg
base64 encoded data .....
.........................
......base64 encoded data
23
MIME-Typen
Content-Type: type/subtype; parameters
Text
 Unterarten zz.B.:
B:
 plain
 html
Image
 Unterarten,
Unterarten zz.B.:
B:
 jpeg
 gif
Audio
Video
 Unterarten z.B.:
 mpeg
 quicktime
Application
 andere Daten, die vom Leser erst
verarbeitet
b it t werden
d müssen,
ü
bevor
b
sie angezeigt werden können
 Unterarten z.B.:
 msword
 octet-stream
 Unterarten
U t
t z.B.:
B
 basic (8-bit mu-law encoded)
 32kadpcm (32 kbps coding)
24
Multipart-Nachricht
From: [email protected]
S bj
Subject:
Picture
i
of
f yummy crepe.
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=98766789
--98766789
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain
Dear Bob,
Please find a picture of a crepe.
--98766789
Content-Transfer-Encoding: base64
Content-Type: image/jpeg
base64
b
64 encoded
d d d
data
t .....
.........................
......base64 encoded data
--98766789-Rechnerkommunikation, Übung 3
25
Mail-Zugriffsprotokolle
MUA
SMTP
Mail- SMTP
Server
Mailserver
des Senders
MailServer
Zugriffs
Zugriffsprotokoll
MUA
Mailserver
des Empfängers
 SMTP: Auslieferung und Ablage der Nachrichten auf Mailserver des
Empfängers
 Mail-Zugriffsprotokoll: Abholen der Nachrichten vom Server
 POP: Post Office Protocol [RFC 1939]
- Autorisierung (MUA <--> Server) und Abholen
 IMAP: Internet Mail Access Protocol [RFC 1730]
- lleistungsfähiger
i t
fähi
(und
( d komplexer)
k
l
)
- Manipulation der auf dem Server gespeicherten Nachrichten
- Verzeichnisse ((Folder)) etc.
 HTTP: GMX, Hotmail , Yahoo! Mail, etc.
26
POP3-Protokoll
Autorisierungsphase
 Befehle des Clients:
 user: Benutzername
 pass: Paßwort
 Antworten des Servers
 +OK
 -ERR
Transaktionsphase, Client:
gibt Nachrichtennummern
 list: g
als Liste aus
 retr: hole Nachricht mit
bestimmter Nummer ab
 dele: lösche Nachricht
 quit
S:
C
C:
S:
C:
S:
+OK POP3 server ready
user b
bob
b
+OK
pass hungry
+OK user successfully
f ll l
logged
d
C:
S:
S:
S:
C:
S:
S:
C:
S
S:
C:
S:
S:
C:
S:
C:
S:
list
1 498
2 912
.
retr 1
<Inhalt Nachricht 1>
.
dele 1
+OK message marked for delete
retr 2
<Inhalt Nachricht 2>
.
dele 2
+OK message marked for delete
quit
+OK POP3 server signing off
27
on
IMAP-Protokoll
IMAP4rev1
RFC 3501 seit 1996
Autorisierungsphase
 Befehle des Clients:
 Befehl ID: a001
 user: mrc
 pass: secret
 Antworten des Servers
 Befehl ID: a001
 OK LOGIN
Transaktionsphase
 Wählen der inbox
 Betragen und löschen der
Mail 12
Abmeldephase
S: * OK IMAP4rev1 Service Ready
C: a00
a001 login
og
mrc
c secret
sec et
S: a001 OK LOGIN completed
C:
S:
S:
S:
S:
S:
S:
C:
S:
S:
S:
S
S:
S:
S:
S:
S:
S:
S:
S:
S:
C:
S:
S:
a002 select inbox
* 18 EXISTS
* FLAGS (\Answered \Flagged
gg
\Deleted \Seen \Draft)
* 2 RECENT
* OK [UNSEEN 17] Message 17 is the first unseen
message
* OK [UIDVALIDITY 3857529045] UIDs valid
a002 OK [READ-WRITE]
[READ WRITE] SELECT completed
a004 fetch 12 body[header]
* 12 FETCH (BODY[HEADER] {342}
Date: Wed, 17 Jul 1996 02:23:25 -0700 (PDT)
From: Terry Gray <[email protected]>
S bj t IMAP4rev1
Subject:
IMAP4
1 WG mtg
t summary and
d minutes
i t
cc: [email protected], John Klensin
<[email protected]>
Message-Id: <[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
)
a004
a005
* 12
a005
OK FETCH completed
store 12 +flags \deleted
FETCH (FLAGS (\Seen \Deleted))
OK +FLAGS completed
C: a006
C
006 logout
l
t
S: * BYE IMAP4rev1 server terminating connection
S: a006 OK LOGOUT completed
28
POP3 und IMAP
POP3
 vorheriges Beispiel nutzt den
„Download-and-Delete“-Modus.
 Bob kann die Nachricht nicht
erneut abholen und lesen, wenn
er einen anderen Mailclient
verwendet
 mit „Download-and-Keep“Modus sind Kopien der
Nachrichten in verschiedenen
Clients möglich
 POP3 ist über die Sitzungen
hinweg
g zustandslos
 üblicherweise TCP Port 110
IMAP
 behält alle Nachrichten an
zentralen Stelle auf dem Server
 Erlaubt es, Nachrichten in
Verzeichnisse (Folder)
einzuordnen
 IMAP behält den Zustand über
Sitzungen hinweg:
 Namen der Verzeichnisse und
Abbildung zwischen den
Nachrichten-IDs und dem
Verzeichnisnamen
 üblicherweise TCP Port 143
29
Anwendungsschicht




HTML
Conditional GET
Authentifizierung
Cookies
E
E-Mail
Mail
 SMTP
 Peer-to-Peer
P
t P
S
Systeme
t
30
Socket-Programmierung mit UDP
UDP: verbindungslos, d.h. kein
Verbindungsaufbau zwischen
Client und Server
 kein Handshaking
g für jedes
j
Paket
 Sender fügt
explizit Ziel-IP-Adresse und –Port
ein
 Empfänger muss die Quell
Quell-IPIP
Adresse und den Quellport aus
dem empfangenen Paket
extrahieren
 UDP: gesendete Daten können in
falscher Reihenfolge empfangen
werden
e de ode
oder verloren
e o e ge
gehen
e
Aus Sicht der Anwendung
UDP bietet unzuverlässige
Üb
Übertragung
einer
i
Gruppe
G
von Bytes (Datagramme) zwischen
Client und Server
31
Client-Server-Socket-Interaktion: UDP
Server
(auf Host hostid)
erzeuge Socket,
port=x, für
eingehende Anforderung (Request):
serverSocket =
DatagramSocket()
Anforderung lesen aus
serverSocket
Antwort schreiben in
serverSocket
unter Angabe der
Client-IP-Adresse
und des Ports
Client
Erzeuge Socket,
clientSocket =
DatagramSocket()
Erzeugung, Adressierung hostid, port=x,
sende Anfrage als Datagramm
über clientSocket
Lesen der
Antwort aus
clientSocket
schließe
clientSocket
32
Beispiel: Java-Server (UDP)
import java.io.
java io *;;
import java.net.*;
Erzeuge
Datagramm-Socket
auf Port 9876
class UDPServer {
public static void main(String args[]) throws Exception
{
DatagramSocket serverSocket = new DatagramSocket(9876);
byte[] receiveData = new byte[1024];
byte[] sendData = new byte[1024];
Reserviere Speicher
für empfangenes
Datagramm
Empfange
Datagramm
while(true)
{
DatagramPacket receivePacket =
new DatagramPacket(receiveData, receiveData.length);
serverSocket receive(receivePacket);
serverSocket.receive(receivePacket);
33
Beispiel: Java-Server (UDP)
int rcvLen = receivePacket.getLength();
String sentence = new String(receivePacket.getData(), 0, rcvLen);
Auslesen
A
l
der
d
IP-Addr.
und Portnum. des
Sende s
Senders
InetAddress IPAddress = receivePacket.getAddress();
int port = receivePacket.getPort();
receivePacket getPort();
String capitalizedSentence = sentence.toUpperCase();
sendData = capitalizedSentence.getBytes();
Erz. Datagramm
zum Senden
an Client
DatagramPacket sendPacket =
new DatagramPacket(sendData,
DatagramPacket(sendData sendData
sendData.length,
length IPAddress
IPAddress,
port);
Schreibe
Datagramm
in Socket
serverSocket.send(sendPacket);
}
}
}
Ende der while-Schleife, zurückspringen und
a f weiteres
auf
eite es Datag
Datagramm
amm warten
a ten
34
Beispiel: Java-Client (UDP)
iimportt java.io.*;
j
i *
import java.net.*;
Erzeuge
InputStream
Erzeuge
Client-Socket
Übersetzung
Hostnamen in IPAdresse mit DNS
class UDPClient {
public static void main(String args[]) throws Exception
{
BufferedReader
B
ff dR d iinFromUser
F
U
=
new BufferedReader(new InputStreamReader(System.in));
DatagramSocket
g
clientSocket = new DatagramSocket();
g
();
InetAddress IPAddress = InetAddress.getByName("hostname");
byte[] sendData = new byte[1024];
byte[] receiveData = new byte[1024];
g sentence = inFromUser.readLine();
();
String
sendData = sentence.getBytes();
35
Beispiel: Java-Client (UDP)
Erzeuge Datagramm
mit
it zu sendenden
d d
Daten, Länge, IPAddr., Port
S d Datagramm
Sende
D t
an Server
DatagramPacket sendPacket =
new DatagramPacket(sendData, sendData.length, IPAddress, 9876);
clientSocket.send(sendPacket);
DatagramPacket receivePacket =
new DatagramPacket(receiveData,
DatagramPacket(receiveData receiveData
receiveData.length);
length);
Lese Datagramm
von Server
clientSocket.receive(receivePacket);
String modifiedSentence =
new String(receivePacket.getData());
System.out.println(
System
out println("FROM
FROM SERVER:"
SERVER: + modifiedSentence);
clientSocket.close();
}
}
36
Anwendungsschicht
 Conditional GET
 Cookies
 E-Mail
 SMTP
 Peer-to-Peer Systeme
37
P2P
 Bittorrent





Sc a
Schwarm:
Peers
ee s für
ü g
gleiche
e c e Datei,
ate , z.B. Tausende
ause de
Chunks: Teile der zu verteilenden Datei, z.B. 256 KB
Tracker: zentraler Server, bei dem sich Peers registrieren
.torrent
torrent-Datei
Datei mit Meta
Meta-Daten
Daten über zu verteilende Datei und Tracker
neuer Peer A tritt Schwarm bei
- A registriert sich bei Tracker und erhält IP-Adressen zufälliger
anderer Peers (z
(z.B.
B 50) des Schwarms
- A baut TCP-Verbindung zu einigen dieser Peers auf, fragt Liste der
Chunks in ihrem Besitz nach und sendet Anfragen für Chunks
- Rarest First: A fragt die seltensten Chunks der Peers zuerst nach
nach,
dadurch gleichmäßige Verteilung
- A misst Antwortsrate der Peers und antwortet an diese in
entsprechendem
p
Anteil der Upload-Rate
p
- neue Nachbarn werden zufällig dazugenommen
- und mehr: Hashing, Pipelining, Random First Piece, Endgame
Model,, Choking,
g, Anti-Snubbing,
g, …
38
P2P
 Beispiel
 auf Web
Web-Seite
Seite befindet
sich .torrent-Datei für
großes SW-Image
 Download mit
Bittorrent Client
39
P2P
 Anzeige der Peers:
 grafische Veranschaulichung:
40
P2P
 Anzeige der bereits heruntergeladenen Teile:
41

Übung 3

Transcrição

Documentos relacionados

Netzwerktechnik CHS Villach Mag. Rainer Swatek Dauer: 2

Truehouse Internet Streaming Installation

Server - Einstellungen IMAP Email – Konten (THUNDERBIRD)

Herzlich willkommen

Vorkonfigurierte Server für Medienpark - silber

Bericht über eine Migration von NT SBS auf Windows 2003

Datenblatt CDxPress 2015

Als PDF downloaden

Webhosting - easyWEB4u

Lokale Testinstallation mit Einrichtung eines MS SQL Server