Internet Applications & Socket Programming

(1)

2: Application Layer 1

Internet

Applications

&

Socket Programming

Niels Christian Juul

5

th

_{lecture on Networks & Protocols}

Roskilde University - Department of Computer Science

E-mail: [email protected] [email protected] [email protected]

Undervisere

❒

Niels Christian Juul

❍

Lektor i datalogi ved Datalogi, RUC (tidligere HHK)

❍

PhD i datalogi (distribueret GC), DIKU

❍

http://www.dat.ruc.dk/~ncjuul

❒

Eric Jul

❍

Professor i datalogi, DistLab, DIKU

❍

PhD i datalogi (Emerald), UW

❍

5 th

_{Lecture on Networks.}

Chapter 2.4-2.8: Application Layer Examples

❒

specific protocols:

❍

smtp

❍

(pop-3)

❍

DNS

❒

programming network applications

❍

socket programming

❍

Java & C & C++

World Wide Web

HTML fremviser WWW Client URL adresse gopher ftp Andre services HTTP Server CGI programmer CGI HTTP transport af fore-spørgsel og svar

(3)

ISO-OSI: Model for datanet

7 Anvendel-seslaget 6 Repræsen-tationslaget 5 Sessions-laget 4 Transport-laget 3 Netværks-laget 2 Forbindel-seslaget 1 Det fysisk lag

TCP

IP

Rutning

IP

TCP

HTTP request (Ex.: Get index.html) HTTP reply (Ex.: text/html ….)

Ethernet TokenRing

Electronic Mail

Three major components:

❒ user agents

❒ mail servers

❒ simple mail transfer

protocol: smtp

User Agent

❒ a.k.a. “mail reader”

❒ composing, editing, reading

mail messages

❒ e.g., Eudora, Outlook, elm,

Netscape Messenger

❒ outgoing, incoming messages

stored on server user mailbox outgoing message queue mail server user agent user agent user agent mail server user agent user agent mail server user agent

SMTP

(4)

Electronic Mail: mail servers

Mail Servers

❒ mailbox contains incoming

messages (yet to be read) for user

❒ message queue of outgoing

(to be sent) mail messages

❒ smtp protocol between mail

servers to send email messages

❍ “client”:

sending mail server

❍ “server”:

receiving mail server

mail server user agent user agent user agent mail server user agent user agent mail server user agent

SMTP

Client / Server

The role of clients and servers in distributed

systems:

❒

Server:

❍ waits for requests, ❍ Calculates, and ❍ returns an answer

❒

Client:

❍ issues requests and

❍ waits to receive an answer.

Dual-roles

(5)

Electronic Mail: smtp

[RFC 821]

❒ uses tcp to reliably transfer email msg from client to

server, port 25

❒ direct transfer: sending server to receiving server ❒ three phases of transfer

❍ handshaking (greeting) ❍ transfer of messages ❍ closure

❒ command/response interaction ❍ commands: ASCII text

❍ response: status code and phrase

❒

messages must be in 7-bit ASCII

Sample smtp interaction

S: 220 hamburger.edu C: HELO crepes.fr

S: 250 Hello crepes.fr, pleased to meet you C: MAIL FROM: <[email protected]>

S: 250 [email protected]... Sender ok C: RCPT TO: <[email protected]>

S: 250 [email protected] ... Recipient ok C: DATA

S: 354 Enter mail, end with "." on a line by itself C: Do you like ketchup?

C: How about pickles? C: .

S: 250 Message accepted for delivery C: QUIT

(6)

try smtp interaction for yourself:

❒

telnet servername 25

❒

see 220 reply from server

❒

enter HELO, MAIL FROM, RCPT TO, DATA, QUIT

commands

above lets you send email without using email client

(reader)

BUT

❒

Remember to enable “local echo” in properties

of the telnet client, and

❒

No misspelling (backspace/del does not delete)

Telnet som Client

❒

Telnet til “wellknown services” på server

❒

Default: telnet til port 23 som giver en

login

❒

Også telnet til andre portnumre

❍

f.x. telnet smtp.it-c.dk 25

❍

Port 25 er SMTP (e-mail service)

❍

SMTP dialog foregår i læsbar skrift

(7)

SMTP kommando syntax

HELO <SP> <domain> <CRLF>

MAIL <SP> FROM:<reverse-path> <CRLF>

RCPT <SP> TO:<forward-path> <CRLF>

DATA <CRLF>

RSET <CRLF>

SEND <SP> FROM:<reverse-path> <CRLF>

VRFY <SP> <string> <CRLF>

EXPN <SP> <string> <CRLF>

HELP [<SP> <string>] <CRLF>

NOOP <CRLF>

Moralsk pegefinger

❒

Kendskab til SMTP gør det rimeligt nemt

at sende anonymt e-mail

❒

Det er naturligvis ikke etisk ansvarligt at

gøre det udover interne eksperimenter i

gruppen

Spørgsmål til de uansvarlige:

❒

Kan modtageren opdage det?

(8)

smtp: final words

❒ smtp uses persistent

connections

❒ smtp requires that

message (header & body) be in 7-bit ascii

❒ certain character strings

are not permitted in message (e.g., CRLF.CRLF). Thus message has to be encoded (usually into either base-64 or quoted printable) ❒ smtp server uses CRLF.CRLF to determine end of message

Comparison with http

❒ http: pull ❒ email: push ❒ both have ASCII

command/response interaction, status codes

❒ http: each object is

encapsulated in its own response message

❒ smtp: multiple objects

message sent in a multipart message

Protocols

❒

A specification of roles and interaction

❒

Use-cases / usage patterns

❒

Content specification

❒

RFCs define

❒

Software survive

(9)

Mail message format

smtp: protocol for exchanging email msgs

RFC 822: standard for text message format:

❒ header lines, e.g., ❍ To: ❍ From: ❍ Subject: different from smtp commands! ❒ body

❍ the “message”, ASCII characters only

header

body

blank line

Message format: multimedia extensions

❒ MIME: multimedia mail extension, RFC 2045, 2056 ❒ additional lines in msg header declare MIME content

type

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

multimedia data type, subtype, parameter declaration method used to encode data MIME version encoded data

(10)

MIME types

Content-Type: type/subtype; parameters

Text

❒ example subtypes: plain, html

Image

❒ example subtypes: jpeg, gif

Audio

❒ exampe subtypes: basic

(8-bit mu-law encoded),

32kadpcm (32 kbps coding)

Video

❒ example subtypes: mpeg, quicktime

Application

❒ other data that must be

processed by reader before “viewable” ❒ example subtypes: msword, octet-stream

Multipart Type

From: [email protected] To: [email protected]

Subject: Picture of 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 encoded data ... ... ...base64 encoded data

(11)

--98766789--2: Application Layer 21

Mail access protocols

❒ SMTP: delivery/storage to receiver’s server ❒ Mail access protocol: retrieval from server

❍ POP: Post Office Protocol [RFC 1939]

• authorization (agent <-->server) and download

❍ IMAP: Internet Mail Access Protocol [RFC 1730]

• more features (more complex)

• manipulation of stored msgs on server

❍ HTTP: Hotmail , Yahoo! Mail, etc.

user agent sender’s mail server user agent

SMTP

_{POP3 or}

IMAP

receiver’s mail server

POP3 protocol

authorization phase

❒ client commands:

❍ user: declare username ❍ pass: password

❒ server responses ❍ +OK

❍ -ERR

transaction phase,

client:

❒ list: list message numbers ❒ retr: retrieve message by

number ❒ dele: delete ❒ quit

C: list S: 1 498 S: 2 912 S: . C: retr 1 S: <message 1 contents> S: . C: dele 1 C: retr 2 S: <message 1 contents> S: . C: dele 2 C: quit

S: +OK POP3 server signing off

S: +OK POP3 server ready C: user alice

S: +OK

C: pass hungry

(12)

Domain Name (adresering)

❒

IP-numbers are hard to remember

❒

DNS knows about the IP-addresse

❒

Hierarcy: Ex. www.it-c.dk

dk

_it-c

www.it-c.dk

linux.it-c.dk

linux

www

/etc/hosts

127.0.0.1 localhost # # # Niels Brock # 130.226.238.2 fiol.nbrock.dk fiol 130.226.238.54 wundee duck 130.226.238.224 kultux 130.226.238.217 elinux

130.226.238.248 linux.nbrock.dk linux www www.nbrock.dk 130.226.238.243 novell1 # # Host Database # 129.142.6.64 danpost.uni-c.dk #

# NCJuul local network #

#

192.168.11.0 ncjuul_LAN

192.168.11.1 mufasa router www test1 n001.ncjuul.dk 192.168.11.2 test2 n002.ncjuul.dk

192.168.11.3 test3 n003.ncjuul.dk 192.168.11.4 test4 n004.ncjuul.dk 192.168.11.5 test5 n005.ncjuul.dk

(13)

DNS: Domain Name System

People:

many identifiers:

❍ SSN, name, Passport #

Internet hosts, routers:

❍ IP address (32 bit)

-used for addressing datagrams

❍ “name”, e.g.,

gaia.cs.umass.edu - used by humans

Q:

map between IP

addresses and name ?

Domain Name System:

❒ distributed database

implemented in hierarchy of many name servers

❒ application-layer protocol

host, routers, name servers to communicate to resolvenames (address/name translation)

❍ note: core Internet

function implemented as application-layer protocol

❍ complexity at network’s

“edge”

DNS name servers

❒

no server has all

name-to-IP address mappings

local name servers:

❍ each ISP, company has

local (default) name server

❍ host DNS query first goes

to local name server

authoritative name server:

❍ for a host: stores that

host’s IP address, name

❍ can perform name/address

translation for that host’s name

Why not centralize DNS?

❒

single point of failure

❒

traffic volume

❒

distant centralized

database

❒

maintenance

(14)

DNS: Root name servers

❒ contacted by local

name server that can not resolve name

❒ root name server: ❍ contacts

authoritative name server if name mapping not known

❍ gets mapping ❍ returns mapping to

local name server

❒ ~ dozen root name

servers worldwide

Simple DNS example

host surf.eurecom.fr wants IP address of

gaia.cs.umass.edu 1. Contacts its local DNS

server, dns.eurecom.fr

2. dns.eurecom.fr contacts root name server, if necessary

3. root name server contacts authoritative name server,

dns.umass.edu, if

necessary _{requesting host}

surf.eurecom.fr gaia.cs.umass.edu

root name server

authorititive name server

dns.umass.edu

local name server

dns.eurecom.fr 1 2 3 4 5 6

(15)

DNS example

Root name server:

❒ may not know

authoratiative name server ❒ may know intermediate name server: who to contact to find authoritative name server requesting host surf.eurecom.fr gaia.cs.umass.edu

root name server

local name server

authoritative name server

dns.cs.umass.edu

intermediate name server

dns.umass.edu

7

8

DNS: iterated queries

recursive query:

❒ puts burden of name

resolution on contacted name server ❒ heavy load?

iterated query:

❒ contacted server

replies with name of server to contact

❒ “I don’t know this

name, but ask this server”

requesting host

surf.eurecom.fr

gaia.cs.umass.edu

root name server

local name server

authoritative name server

dns.cs.umass.edu

intermediate name server

dns.umass.edu

7

8

(16)

DNS: caching and updating records

❒

once (any) name server learns mapping, it

caches

mapping

❍

cache entries timeout (disappear) after some

time

❒

update/notify mechanisms under design by IETF

❍ RFC 2136

❍ http://www.ietf.org/html.charters/dnsind-charter.html

DNS records

DNS:

distributed db storing resource records

(RR)

❒

Type=NS

❍ name is domain (e.g.

foo.com)

❍ value is IP address of

authoritative name server for this domain

RR format:

(name, value, type,ttl) ❒

Type=A

❍ name is hostname ❍ value is IP address

❒

Type=CNAME

❍ name is an alias name

for some “cannonical” (the real) name

❍ value is cannonical

name

❒

Type=MX

❍ value is hostname of

mailserver associated with

(17)

DNS protocol, messages

DNS protocol :

query

and

repy

messages, both with

same

message format

msg header

❒ identification: 16 bit # for

query, repy to query uses same # ❒ flags: ❍ query or reply ❍ recursion desired ❍ recursion available ❍ reply is authoritative

DNS protocol, messages

Name, type fields for a query RRs in reponse to query records for authoritative servers additional “helpful” info that may be used

(18)

DNS lookup

❒

Unix:

❍

nslookup command

❒

Windows:

❍

ws-ping pro pack from www.ipswitch.com

❍

Look at any WinSock Client Programs, e.g.

TUCOWS

Client-server paradigm

Typical network app has two

pieces: client and server applicationtransport network data link physical application transport network data link physical Client:

❒ initiates contact with server

(“speaks first”)

❒ typically requests service from

server,

❒ for Web, client is implemented

in browser; for e-mail, in mail reader

Server:

❒ provides requested service to

client

❒ e.g., Web server sends

requested Web page, mail

request

(19)

Application-layer protocols (cont).

API: application

programming interface

❒

defines interface

between application

and transport layer

❒

socket: Internet API

❍ two processes

communicate by sending data into socket, reading data out of socket

Q:

how does a process

“identify” the other

process with which it

wants to communicate?

❍ IP address of host

running other process

❍ “port number” - allows

receiving host to determine to which local process the message should be delivered

… lots more on this later.

Services provided by Internet

transport protocols

TCP service:

❒ connection-oriented: setup

required between client, server

❒ reliable transport between

sending and receiving process

❒ flow control: sender won’t

overwhelm receiver

❒ congestion control: throttle

sender when network overloaded

❒ does not providing: timing,

minimum bandwidth guarantees

UDP service:

❒ unreliable data transfer

between sending and receiving process

❒ does not provide:

connection setup, reliability, flow control, congestion control, timing, or bandwidth guarantee

Q: why bother? Why is there a UDP?

(20)

Socket programming

Socket API

❒ introduced in BSD4.1 UNIX,

1981

❒ explicitly created, used,

released by apps

❒ client/server paradigm ❒ two types of transport

service via socket API:

❍ unreliable datagram ❍ reliable, byte

stream-oriented

a host-local, application-created/owned,

OS-controlled interface (a “door”) into which application process can

both send and receive messages to/from

another (remote or local) application process

socket

Goal:

learn how to build client/server application that

communicate using sockets

Socket Applications - How ?

Network Application Programming Interface (API)

❒

Den tjeneste som operativsystemet tilbyder

❒

Grænsefladen mellem en applikation og

netværksprotokol implementationerne

Application

Network API

Protocol A

(21)

Socket API

❒

Generic Programming Interface

❒

Understøttelse af både besked-orienteret og

forbindelses-orienteret kommunikation.

❒

Tilstræber at fungere som normal I/O (i den

omfang det har mening)

❒

Operativsystem uafhængigt

❒

Oprindeligt udviklet til Unix-varianter fra

Berkeley (BSD Unix)

❒

Understøtter flere protokoller (og protokol

familier)

Socket-programming using TCP

Socket:

a door between application process and

end-end-transport protocol (UCP or TCP)

TCP service:

reliable transfer of bytes from one

process to another

process TCP with buffers, variables socket controlled by application developer controlled by operating system host or server process TCP with buffers, variables socket controlled by application developer controlled by operating system host or server internet

(22)

Socket programming with TCP

Client must contact server ❒ server process must first

be running

❒ server must have created

socket (door) that welcomes client’s contact

Client contacts server by: ❒ creating client-local TCP

socket

❒ specifying IP address, port

number of server process

❒ When client creates socket:

client TCP establishes connection to server TCP

❒ When contacted by client, server TCP creates new socket for server process to communicate with client

❍ allows server to talk with

multiple clients

TCP provides reliable, in-order transfer of bytes (“pipe”)

between client and server

application viewpoint

TCP Client/Server skabelon

WSAStartup

socket

connect

send

recv

closesocket

WSACleanup

WSAStartup

socket

bind

listen

accept

recv

send

closesocket

WSACleanup

Server

Cl

ient

Cl

ient

(23)

Socket programming with TCP

Example client-server app: ❒ client reads line from

standard input (inFromUser stream) , sends to server via socket (outToServer stream)

❒ server reads line from socket ❒ server converts line to

uppercase, sends back to client

❒ client reads, prints modified

line from socket

(inFromServer stream)

Input stream: sequence of bytes into process

Output stream: sequence of bytes out of process

client socket

inFromUser _outToServer

iinFromServer

Client/server socket interaction: TCP

wait for incoming connection request connectionSocket = welcomeSocket.accept() create socket, port=x, for incoming request: welcomeSocket = ServerSocket() create socket,

connect to hostid, port=x

clientSocket = Socket()

close

connectionSocket

read reply from

clientSocket

close

clientSocket

Server

(running on hostid)

Client

send request using

clientSocket

read request from

connectionSocket

write reply to

connectionSocket

TCP connection setup

(24)

Example: Java client (TCP)

import java.io.*; import java.net.*; class TCPClient {

public static void main(String argv[]) throws Exception {

String sentence;

String modifiedSentence; BufferedReader inFromUser =

new BufferedReader(new InputStreamReader(System.in)); Socket clientSocket = new Socket("hostname", 6789); DataOutputStream outToServer = new DataOutputStream(clientSocket.getOutputStream()); Create input stream Create client socket, connect to server Create output stream attached to socket

Example: Java client (TCP), cont.

BufferedReader inFromServer = new BufferedReader(new InputStreamReader(clientSocket.getInputStream())); sentence = inFromUser.readLine(); outToServer.writeBytes(sentence + '\n'); modifiedSentence = inFromServer.readLine();

System.out.println("FROM SERVER: " + modifiedSentence); clientSocket.close(); } } Create input stream attached to socket Send line to server Read line from server

(25)

Example: Java server (TCP)

import java.io.*; import java.net.*; class TCPServer {

public static void main(String argv[]) throws Exception {

String clientSentence; String capitalizedSentence;

ServerSocket welcomeSocket = new ServerSocket(6789);

while(true) {

Socket connectionSocket = welcomeSocket.accept(); BufferedReader inFromClient = new BufferedReader(new InputStreamReader(connectionSocket.getInputStream())); Create welcoming socket at port 6789 Wait, on welcoming

socket for contact by client Create input stream, attached to socket

Example: Java server (TCP), cont

DataOutputStream outToClient =

new DataOutputStream(connectionSocket.getOutputStream());

clientSentence = inFromClient.readLine(); capitalizedSentence = clientSentence.toUpperCase() + '\n'; outToClient.writeBytes(capitalizedSentence); } } } Read in line from socket Create output stream, attached to socket

Write out line to socket

End of while loop, loop back and wait for another client connection

(26)

Kommunikationsendepunkter

❒

Services:

❍

Service navne

❍

Portnumre

❍

Se filen: /etc/services

❍

Port < 1000 er “wellknown services”

❒

IP-adresser

❍

IP numre (dotted decimal)

❍

IP navne (domain name)

❍

Se filen: /etc/hosts

❍

eller kontakt den lokale DNS

Wellknown services & port no.

#

# services This file describes the various services that are # available from the TCP/IP subsystem. It should be # consulted instead of using the numbers in the ARPA # include files, or, worse, just guessing them. #

# Version: @(#)/etc/services 2.00 04/30/93 #

# Author: Fred N. van Kempen, <[email protected]> #

tcpmux 1/tcp # rfc-1078 echo 7/tcp

echo 7/udp

discard 9/tcp sink null discard 9/udp sink null systat 11/tcp users daytime 13/tcp

daytime 13/udp netstat 15/tcp

qotd 17/tcp quote

chargen 19/tcp ttyatst source chargen 19/udp ttytst source

(27)

Wellknown services & port no.

ftp-data 20/tcp

ftp 21/tcp telnet 23/tcp

smtp 25/tcp mail time 37/tcp timserver time 37/udp timserver

rlp 39/udp resource # resource location name 42/udp nameserver

whois 43/tcp nicname # usually to sri-nic domain 53/tcp

domain 53/udp

mtp 57/tcp # deprecated bootps 67/udp # bootp server bootpc 68/udp # bootp client tftp 69/udp

gopher 70/tcp # gopher server rje 77/tcp

finger 79/tcp

http 80/tcp # www is used by some broken www 80/tcp # progs, http is more correct link 87/tcp ttylink

kerberos 88/udp kdc # Kerberos authentication--udp kerberos 88/tcp kdc # Kerberos authentication--tcp

Socket programming with UDP

UDP: no “connection” between client and server

❒ no handshaking

❒ sender explicitly attaches

IP address and port of destination

❒ server must extract IP

address, port of sender from received datagram

UDP: transmitted data may be received out of order, or lost

application viewpoint

UDP provides unreliable transfer of groups of bytes (“datagrams”)

(28)

Simpel UDP Client/Server

skabelon

WSAStartup socket sendto recvfrom WSACleanup WSAStartup socket bind recvfrom sendto WSACleanup

Server

Cl

ient

Cl

ient

Client/server socket interaction: UDP

close

clientSocket

Server

(running on hostid)

read reply from

clientSocket

create socket,

clientSocket = DatagramSocket()

Client

Create, address (hostid, port=x, send datagram request

using clientSocket create socket, port=x, for incoming request: serverSocket = DatagramSocket()

read request from

serverSocket write reply to serverSocket specifying client host address, port umber

(29)

Example: Java client (UDP)

import java.io.*; import java.net.*;

class UDPClient {

public static void main(String args[]) throws Exception {

BufferedReader inFromUser =

new BufferedReader(new InputStreamReader(System.in));

DatagramSocket clientSocket = new DatagramSocket();

InetAddress IPAddress = InetAddress.getByName("hostname");

byte[] sendData = new byte[1024]; byte[] receiveData = new byte[1024];

String sentence = inFromUser.readLine(); sendData = sentence.getBytes(); Create input stream Create client socket Translate hostname to IP address using DNS

Example: Java client (UDP), cont.

DatagramPacket sendPacket =

new DatagramPacket(sendData, sendData.length, IPAddress, 9876);

clientSocket.send(sendPacket);

DatagramPacket receivePacket =

new DatagramPacket(receiveData, receiveData.length); clientSocket.receive(receivePacket); String modifiedSentence = new String(receivePacket.getData());

System.out.println("FROM SERVER:" + modifiedSentence); clientSocket.close();

} } Create datagram with data-to-send, length, IP addr, port Send datagram

to server Read datagram from server

(30)

Example: Java server (UDP)

import java.io.*; import java.net.*;

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];

while(true) {

DatagramPacket receivePacket =

new DatagramPacket(receiveData, receiveData.length); serverSocket.receive(receivePacket);

Create datagram socket at port 9876

Create space for received datagram Receive datagram

Example: Java server (UDP), cont

String sentence = new String(receivePacket.getData());

InetAddress IPAddress = receivePacket.getAddress();

int port = receivePacket.getPort();

String capitalizedSentence = sentence.toUpperCase(); sendData = capitalizedSentence.getBytes();

DatagramPacket sendPacket =

new DatagramPacket(sendData, sendData.length, IPAddress, port); serverSocket.send(sendPacket); } } }

Get IP addr port #, of sender Write out datagram to socket

End of while loop, loop back and wait for another datagram Create datagram

(31)

Echo

Network Working Group J. Postel Request for Comments: 862 ISI May 1983

This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet that choose to implement an Echo Protocol are expected to adopt and implement this standard.

A very useful debugging and measurement tool is an echo service. An echo service simply sends back to the originating source any data it receives.

UDP Based Echo Service

Another echo service is defined as a datagram based application on UDP. A server listens for UDP datagrams on UDP port 7. When a datagram is received, the data from it is sent back in an answering datagram.

Echo server

UDP Echo server skal gentage løkken:

❒

lytte på speciel port

❒

modtage en pakke

❒

finde den reelle længde på pakken og sende

(32)

Simpel UDP Client/Server

skabelon

WSAStartup socket connect send recv WSACleanup WSAStartup socket bind recvfrom sendto WSACleanup

Server

Cl

ient

Cl

ient

Dummy call

Chapter 2: Summary

❒

application service

requirements:

❍ reliability, bandwidth, delay ❒

client-server paradigm

❒

Internet transport

service model

❍ connection-oriented, reliable: TCP ❍ unreliable, datagrams: UDP

Our study of network apps now complete!

❒

specific protocols:

❍ http ❍ ftp ❍ smtp, pop3 ❍ dns ❒

socket programming

❍ client/server implementation

(33)

Chapter 2: Summary

❒

typical request/reply

message exchange:

❍ client requests info or

service

❍ server responds with

data, status code

❒

message formats:

❍ headers: fields giving

info about data

❍ data: info being

communicated

Most importantly: learned about protocols

❒ control vs. data msgs ❍ in-based, out-of-band ❒ centralized vs. decentralized ❒ stateless vs. stateful ❒ reliable vs. unreliable msg transfer ❒ “complexity at network edge” ❒ security: authentication

Socket API from C

❒

Library of procedures may be used from

the C programming language.

❒

These are the underlying mechnism for the

(34)

accept()

❒

En TCP server afventer opkald på en passiveret

socket med kaldet af accept:

int accept(socket, remoteadr, addrlen)

❒

Efter listen() kaldes accept(), f.eks.:

newsock = accept(msock,

(struct sockaddr *)&fsin,

&alen);

❒

hvor fsin er af typen struct sockaddr_in

og

alen

er størrelsen af fsin strukturen

Opkalds

socket

Opkalds

socket

Data socket

Unix Descriptor Table

Descriptor Table

0

1

2

3

4 Data structure for file 0

Data structure for file 0

Data structure for file 1

Data structure for file 2

(35)

Socket Descriptor Data Structure

0

1

2

3

4 Descriptor Table

Descriptor Table

Family: PF_INET

Service: SOCK_STREAM

Local IP: 192.168.1.4

Remote IP: 123.45.6.78

Local Port: 2249

Remote Port: 3726

Family: PF_INET

Service: SOCK_STREAM

Local IP: 192.168.1.4

Remote IP: 123.45.6.78

Local Port: 2249

Remote Port: 3726

Generel socket adresse

struct sockaddr {

u_short

sa_family;

char sa_data[14];

};

❒

sa_family

angiver adresse typen

❒

sa_data

angiver adressen (værdien)

❒

For Internet adresse familien:

AF_INET består adressen af:

❍

16 bit port nummer

❍

32 bit IP adresse

(36)

sa_family

sa_data

AF_INET

sin_port

sin_addr

sockaddr

_in

TCP/IP Adresser

❒

Vi behøver ikke tage os af sockaddr fordi

vi alligevel kun vil arbejde med Internet

protokol familien

❒

Vi kan nøjes med at bruge sockaddr_in

❒

C funktionerne, som udgør socket API,

forventer dog at blive kaldt med parametre

af typen sockaddr

❒

Derfor anvender vi typecast

(struct sockaddr*)

foran pointer parametre af typen

sockaddr_in

(37)

Oprettelsen af en socket

int socket(

int family,int type,

int proto);

family

angiver protokol familien:

❍ PF_INET for TCP/IP

❒

type

angiver hvilken type service der ønskes:

❍ SOCK_STREAM for TCP/IP ❍ SOCK_DGRAM for UDP/IP

❒

protocol

angiver den specifikke protokol:

❍ dvs. valg mellem TCP og UDP

❍ normalt betyder 0 default (i forhold til type )

Prot

oc

ol f

am

ily

Interne

t: P

F_IN

ET

Prot

oc

ol f

am

ily

Inte

rnet

: P

F_IN

ET

socket()

❒

Systemkaldet socket() returnerer

❍

en socket descriptor (et heltal, -1 ved fejl)

❍

Returtype: SOCKET

❍

ligesom “file descriptor”

socket() allokerer de nødvendige ressourcer for

kommunikationens endepunkt

❍

men kaldet tager sig ikke af adressering af

(38)

Tildeling af adresse til socket

❒

Systemkaldet bind() bruges til at knytte en

adresse til en eksisterende socket

int bind(int sockfd,

struct sockaddr *myaddr,

int addrlen);

❒

bind returns 0 if successfull or -1 on error.

Ad

dress fami

ly

Inte

rnet

: A

F_IN

ET

Ad

dress fami

ly

Inte

rnet

: A

F_IN

ET

❒

kaldet bind() tildeler adressen angivet i

sockaddr

structure til socket descriptor.

❒

Hvis vi kalder bind() med en sockaddr_in

structure bruges “typecast”:

bind( mysock,

(struct sockaddr*) &myaddr,

sizeof(myaddr) );

(39)

bind() eksempel

int mysock;

struct sockaddr_in myaddr;

mysock = socket(PF_INET,SOCK_STREAM,0);

myaddr.sin_family = AF_INET;

myaddr.sin_port = htons( portnum ); myaddr.sin_addr = htonl( ipaddress); bind(mysock, &myaddr, sizeof(myaddr));