Un calcolatore può eseguire più processi server?

ho un dubbio riguardo il significato di server quando si parla di name server, mail server e web server. Se intesi come processi server, uno stesso host può eseguire processi name server, mail server e web server?

1) Un calcolatore può eseguire moltissimi processi. Di fatto, l'utente di un calcolatore non ha la minima idea di quanti processi siano in esecuzione sul proprio calcolatore.
2) Ogni processo può essere un server, in base alla definizione che ne abbiamo dato a lezione.

Da 1 e 2 discende logicamente che ogni calcolatore può eseguire moltissimi processi server. L'unico vincolo è che processi server diversi devono stare in attesa di richieste di connessione su numeri di porta diversi.

Poi quanti e quali processi server siano in esecuzione su un dato calcolatore è un altro problema.

A titolo di cronaca, la figura qui sotto mostra l'elenco dei processi server che in questo momento sono in attesa di richieste di connessione sul mio PC, un normalissimo Windows 10. Ogni riga corrisponde alla disponibilità ad aprire connessioni su un numero di porta (nascosti dal rettangolo verticale, ovviamente sono tutti diversi tra loro). Ci sono una trentina di processi server:

Poi ci sono, in aggiunta, i processi server UDP. Sugli smartphone o sui tablet la situazione è analoga.

Spero che adesso il discorso sia chiaro.

Spero anche che sia evidente che ognuno di noi si fida implicitamente di dispositivi all'interno dei quali succedono una miriade di cose del tutto misteriose ed ampiamente incontrollabili.

Domande e risposte sulle primissime lezioni (ANCORA)

1) Si possono esprimere come segue i seguenti termini?

mail server = host che esegue il processo server responsabile per uno o più domini mail;

web server = host che esegue il processo server responsabile per uno o più nomi di host a cui sono associati il/gli indirizzo/i IP 

name server = host che esegue il processo server responsabile per una zona

c'è la solita ambiguità sul significato di "server", che può significare host o processo;

comunque non ho capito niente sulla domanda web;

2) Un name server è sia mail server che web server? Un name server viene chiamato mail server se ci riferiamo solo ai domini mail o sono due entità separate?

Un name server non c'entra assolutamente nulla con un mail server, il quale non c'entra assolutamente nulla con un web server. Quale slide o frase che ho detto ha fatto sorgere questa interpretazione?

3) In riferimento all'albero della slide 43 (2A_DNS): se un client invia la richiesta fluit.cs.vu.nl, A?, il server che darà le response finale (cioè quello che ha il RR richiesto) è il name server della zona cs.vu.nl? 

Si

4) Se voglio sapere se www.corriere.it è una zona (oppure se corriere.it è una zona), devo fare una richiesta di tipo NS a quale nameserver?

Ad un name server qualunque; se quel name server supporta risoluzione ricorsiva allora troverà lo RR richiesto; se non la supporta allora mi risponderà con degli RR tali da permettermi di proseguire la ricerca.

La domanda in linea generale è: come fa un client a conoscere l'indirizzo IP del nameserver a cui fa la request (sa che il numero di porta è 53 ma l'indirizzo IP?

"configurato" = ne conosce a priori l'indirizzo TCP (cos'altro potrebbe significare?)

Supponendo faccia la richiesta di tipo A, si creerebbe la nuova domanda: come fa a conoscere l'indirizzo IP del server a cui fa questa richiesta?)

??? L'indirizzo IP del server a cui si invia la richiesta deve essere noto a priori. Per telefonare ad una persona devo conoscerne già il numero telefonico.

5) I top level domain sono tutti zone a sè stanti?

Si

6) Il router funge da server per il client dell'organizzazione e da client con modulo resolver verso il nameserver dell'organizzazione? Il nameserver di un'organizzazione coincide con quello della zona gestita dall'organizzazione?  Una stessa organizzazione può gestire più zone? 

Domanda #6 contiene tre domande.

Un router, come dice il nome, è un router. Non è un server e non è un client. E' una entità che è completamente invisibile alle applicazioni. Opera ad un livello di astrazione inferiore, quello che realizza il trasporto effettivo dei messaggi e che studieremo nella seconda parte del corso. Io ho accennato alla sua esistenza solo per fare capire come mai alcune configurazioni DNS sono possibili in teoria ma non lo sono nella pratica.

Il nameserver di una organizzazione può essere primario o secondario di una o più zone. Ovviamente se una organizzazione gestisce una zona allora quel nameserver sarà primario o secondario di quella zona.

7) L'indirizzo IP di un nome di dominio può coincidere con l'indirizzo IP del nome della zona a cui appartiene quel dominio? Se sì, succede in casi specifici?

Ad esempio, dati i RR:    it       NS  dns.it

                                    dns.it  A    IP1                                

Alla richiesta: it, A? La response sarà it  A  IP2.

Se il nameserver della zona it appartiene alla zona it, si avrà IP1=IP2?

La frase L'indirizzo IP di un nome di dominio può coincidere con l'indirizzo IP del nome della zona è ambigua: un nome di zona non ha indirizzo IP; ciò che può avere indirizzo IP è il name server di quella zona.

Una zona è una pera ed un name server è una scarpa; entità di tipo radicalmente diverso. Sia la pera sia la scarpa, possono avere un nome.

Detto questo, con quei RR, se la request è "it A ?" allora la risposta sarà "dominio inesistente"; non esiste nessun RR di nome it e valore A. E' impossibile, con quei RR, che una risposta sia "it A IP2": proprio perché quel RR non esiste.

8) In riferimento all'esercizio 3 di preparazione alla prima provetta (riporto il testo)

La posta elettronica per il dominio topolinia.it viene memorizzata nel server

basettoni.topolinia.it . Cioè, il name server primario per la zona topolinia.it contiene

nel proprio zone file la riga:

topolinia.it MX basettoni.topolinia.it

All’istante t0, l’amministratore toglie dallo zone file del name server primario per topolinia.it la

riga precedente, aggiunge la riga seguente e non effettua nessun altro cambiamento allo zone file:

topolinia.it MX pluto.topolinia.it

E’ possibile che, a istanti t1>t0, la posta elettronica per l’utente a@topolinia.it venga recapitata su

basettoni.topolinia.it invece che su pluto.topolinia.it ? Se la risposta è no,

spiegare il motivo. Se la risposta è si, fornire almeno due esempi in cui, a istanti t1> t0, la posta arriva su basettoni.topolinia.it .

E' possibile se il server secondario non è ancora aggiornato, cioè nel tempo tra t0 e t1 il secondario non ha contattato il primario perciò non gli sono state comunicate le modifiche. In questa situazione se alla request del client risponde questo server secondario non aggiornato, la posta elettronica potrebbe essere recapitata sul server basettoni.topolinia.it.

Quali altre situazioni sono possibili come esempio?

Risposta corretta. Altre situazioni possibili si possono avere a causa del caching, argomento che vedremo nella prossima lezione.

Domande e risposte sulle primissime lezioni

1) E' corretto dire che un servizio di comunicazione utilizza un protocollo di comunicazione? O sono sinonimi?

E' corretto e non sono sinonimi.

Si può dire che un servizio di comunicazione TCP/UDP è il layer superiore del software di rete (=sistema operativo)? (slide 40 General)

Si

2) Possono esistere servizi affidabili senza connessione o servizi orientati alla connessione che generano duplicati?

In linea di principio si.

3) Se si inviano 3 messaggi con TCP ma la connessione viene interrotta, potrebbero arrivare 2 messaggi e solo alcuni byte del terzo messaggio? (visti dal ricevente come un unico flusso di byte)

Si.

4) Le procedure dell'interfaccia socket sono in tutto 8? (socket, bind, listen, accept, connect, send, receive, close)

Si, con l'osservazione che noi abbiamo visto procedure idealizzate (un sottoinsieme semplificato della realtà).

5) I processi server che non hanno privilegi di amministratore (non root) possono avere solo numero di porta >1024 come i client dato che il sistema operativo rifiuta di assegnare port number <1024? E perchè si parla di sistema operativo che assegna port number lato server, non dovrebbe essere l'applicativo a sceglierlo? (slide 68 General)

Quanto dice è impreciso perché il discorso dei privilegi di amministratore è molto più ampio e complicato di ciò che abbiamo visto noi.

L'unica cosa che è importante sapere è che se un processo ha un socket s ed esegue bind(s,num) con num<1024 allora il sistema operativo esegue la bind() solo se il processo ha i privilegi di amministratore (e, ovviamente, il numero di porta num è libero). Notare che se il processo esegue bind allora è un server.

6) Oulook per gestire la posta elettronica è un client che si può collegare a più server? (se ad esempio gestisce più caselle di posta elettronica)

Si

7) L'indirizzo IP del client viene scelto dal sistema operativo come il suo port number? O è quello del nodo su cui si trova il client?

Gli indirizzi IP non sono scelti dagli applicativi. Un applicativo ha l'indirizzo IP del proprio nodo. Vedremo nella seconda parte del corso come sono assegnati gli indirizzi IP ai nodi.

8) L'indirizzo IP di un calcolatore è legato alla sua posizione fisica? (per la slide 43 General no, ma per la slide 27 DNS l'indirizzo IP viene modificato quando si sposta fisicamente un calcolatore)

Si, con l'osservazione che il legame è indiretto e difficile da spiegare in modo sintetico in questo momento. Due calcolatori potrebbero essere l'uno accanto all'altro ed avere indirizzi IP completamente diversi tra loro. Un calcolatore potrebbe muoversi di pochi metri e mantenere il proprio indirizzo IP oppure essere obbligato a cambiarlo.

Per il momento conviene avere questo schema mentale: se un calcolatore si sposta di decine di metri allora deve cambiare il proprio indirizzo IP. Ripeto, non è proprio così ma per il momento è utile pensare che sia così.

(slide che aggiungerò il prossimo anno)

Socket: processi server su uno stesso nodo

Si considerino 4 nodi diversi NSA, NSB, NX, NY.

Il processo server SA in esecuzione su NSA esegue il codice seguente:

int t; t=socket(…); bind(t,25,…); listen(t,…); ... interazione con processi client...

Il processo server SB in esecuzione su NSB esegue il codice seguente:

int t; t=socket(…); bind(t,110,…); listen(t,…); ... interazione con processi client...

Su NX sono in esecuzione processi client X1,X2,X3 e su NY sono in esecuzione processi client Y1,Y2,Y3.

All’istante t0 SA ha due connessioni aperte, una con X1 ed una con X2; SB ne ha aperte quattro: con X3, Y1, Y2, Y3.

1.       ....

2.       Si assuma adesso che SA ed SB siano in esecuzione sullo stesso nodo NSA invece che su due nodi diversi. Se lo scenario descritto è ancora possibile, allora elencare i numeri di porta delle due estremità di ogni connessione. Altrimenti spiegare perché lo scenario descritto non è realizzabile.

• "Non realizzabile perché da come è scritto il codice i due processi server dovrebbero condividere lo stesso welcoming socket t su porte diverse, il che non è possibile". Questo non ha il minimo senso. "t" è il nome di una variabile. Non è il nome di un socket (nozione che peraltro non abbiamo mai definito: quando mai abbiamo parlato di nome di un socket?). Come certamente dovete sapere dai corsi precedenti, processi nello stesso nodo possono usare variabili con lo stesso nome, poiché le variabili di un processo sono visibili solo a quel processo (a meno di casi particolari che non avete visto in nessun corso). Staremmo freschi se quando si lancia un programma P dovessimo sempre incrociare le dita sperando che P non sia stato scritto usando nomi di variabile usati anche in altri programmi che in quel momento sono già in esecuzione.
• "Non realizzabile perché due server non possono essere in esecuzione sullo stesso nodo". Per quale motivo? Chi l'ha mai detto? Non ha il minimo senso.
• Non è uno scenario possibile in quanto ci può essere una o più richieste tra un dato client e un dato server". Testuale. A parte la sintassi traballante, qual'è la logica in questa affermazione?
• "Lo scenario descritto non è più possibile: non ci possono essere due processi server con numeri di porta diversi su un unico nodo". E perché?
• "Non realizzabile perché avrei due processi server su uno stesso nodo e i processi client possono invece connettersi con un unico server istante per istante" Qual'è la logica? In entrambi gli scenari ogni processo client è collegato con un solo processo server. Se avesse confuso "processo" con "nodo", allora il secondo scenario sarebbe stato con un solo (nodo) server invece che con due (nodi) server, per cui in base a quella spiegazione sarebbe stato realizzabile solo il secondo. A parte la logica che mi sfugge, il ragionamento è comunque sbagliato. Quando mai abbiamo detto che un client si può collegare con un unico server istante per istante? Abbiamo detto, nelle primissime slide del corso per fare una introduzione, che quello è il caso comune. Comune non significa l'unico che può esistere. Inoltre, quando un browser visualizza una pagina si collega a solo un server per volta? Abbiamo anche detto infinite volte che un browser esegue tante azioni parallele. E un browser può avere tanti tab aperti, per cui può avere tante connessioni aperte.
• "Non realizzabile perché su un nodo tutti gli N+1 socket del server devono essere associati allo stesso numero di porta" Tralasciamo cosa sia N. Risposte di questo genere mi sorprendono completamente. Posso capire che uno non abbia capito un concetto, anche se si tratta di un concetto base. Ma faccio fatica a capire l'apparente assenza di logica (il che mi pare molto più grave). Se invece di un nodo si hanno più nodi allora gli N+1 socket del server non devono essere associati allo stesso numero di porta?
•  "SA avrà impegnate due porte diverse tra di loro con port number maggior di 1024". Il testo dice che SA è un processo server. Quella affermazione, quindi, non ha il minimo senso. "mentre X1 e X2 avranno la connessione su un PN maggiore di 1024 ma non necessariamente diverso". Diverso rispetto a chi? X1 diverso da X2? o cosa? "Discorso simile per SB, avrà la connessione su 4 porte diverse tra loro (con PN>1024) mentre X3,Y1,Y2,Y3, avranno una connessione su una PN >1024". Evidentemente su questa parte di programma c'è il buio completo.
• "Non è possibile in quanto su un nodo devo avere in esecuzione un (sottolineato un) processo server". Quando mai abbiamo fatto questa affermazione? Non è una domanda polemica, davvero non capisco da dove possa sorgere questo dubbio. Anche se fosse così, comunque, la frase sarebbe imprecisa: "devo" andrebbe sostituito da "posso" o qualcosa del genere. C'è poi un'apparente assenza di logica che non riesco a comprendere e che mi preoccupa (vedi anche il punto 24); la frase infatti termina con "è infatti il processo server a determinare il numero di porta del server". Come fa una delle due affermazioni a motivare l'altra?

Socket UDP

lei scrive che nel caso di UDP il server e il client eseguono le STESSE operazioni di TCP, tranne che per il send e il receive (quindi solo l'application layer cambia). Giustamente, essendo connectionless, nel send dovrò includere anche l'indirizzo TCP del destinatario, e nel receive riceverò anche l'indirizzo TCP del mittente. Non mi è chiaro tuttavia qualche particolare:

1. se faccio da server con UDP, nell'application layer non uso mai di fatto il socket, nè per inviare nè per ricevere (in particolare per ricevere mi sembra di aver capito che passo come parametro la porta su cui sono in ascolto). Quindi che senso ha creare il socket, fare il bind e il listen se poi scrivo {msg,TCP-addr}=receive(port num)?
2. se faccio da client valgono le stesse considerazioni di prima: che senso ha creare il socket se poi non lo uso per inviare/ricevere? Inoltre mi turba il connect(..): non abbiamo detto che siamo connectionless? Per concludere, visto che per ricevere devo sapere su che porta ricevere (come prima, sempre se ho capito bene), quando faccio {msg,TCP-addr}=receive(port) sul client, devo quindi sapere che porta mi è stata assegnata dal sistema operativo?

Effettivamente la slide 70 è ambigua. Dice "identico a quanto visto" ma è una descrizione superficiale.

E' "identico" in prima approssimazione, nel senso che è tutto identico a parte il fatto (non secondario) che non si crea una connessione: il server crea un socket, ci associa un port number ed attende richieste; quando riceve una request, risponde a chi ha inviato la request; il client invia request al server ed attende response.

Inoltre, la slide 71 è una semplificazione della realtà. I dubbi che espone ai punti 1 e 2 sono legittimi, perché discendono dalla slide 71 ma non si verificano nella realtà. Spiego più sotto quanto accade nella realtà, precisando che ai fini degli esami basta quanto è descritto nelle slide 70 e 71. La faccenda è infatti un pò intricata, eccessivamente intricata per i nostri fini.

Noi abbiamo detto che un socket è una estremità di tubo. Abbiamo anche accennato che nella realtà i socket sono complicati da usare anche perché sono generali, sono cioè utilizzabili con più protocolli. In particolare, i socket veri si usano anche con UDP. I socket sono cioè un generico "endpoint di comunicazione". Qualsiasi protocollo di comunicazione voglia usare un applicativo, lo deve fare attraverso i socket.

Quando un applicativo crea un socket, specifica con quale protocollo lo vuole usare.

Il server esegue s:=socket("voglio UDP"), bind(s, port-number) e poi una variante di receive(s) che torna due risultati: il messaggio ricevuto e l'indirizzo UDP del mittente (coppia IP-address, port-number; dico indirizzo UDP perché i numeri di porta UDP sono nello stesso intervallo dei numeri di porta TCP ma sono entità diverse, slide 72); poi risponde con una variante di send(s,msg) che ha un argomento in più rispetto a quella che abbiamo visto: l'indirizzo UDP del destinatario; tale indirizzo sarà quello da cui ha ricevuto il messaggio precedente;

Il client esegue s:=socket("voglio UDP"), poi la stessa variante di send(s,msg) vista sopra, in cui come indirizzo UDP del destinatario specificherà il server; poi esegue la stessa variante di receive(s) vista sopra, verificando che la risposta sia arrivata effettivamente dal server (altrimenti la scarta ed esegue nuovamente receive).

Se qualcuno vuole farsi venire il mal di testa, qui sotto c'è la descrizione di send e receive su Linux. Potrete toccare con mano che la realtà ha spessissimo molti dettagli che sono inutili o dannosi da un punto di vista didattico (http://bartoli-alberto.blogspot.it/2015/03/come-organizzo-lo-studio-di-internet.html).

http://linux.die.net/man/2/recvfrom

http://linux.die.net/man/2/sendto

Socket: creazione, uso, natura

1) il client quando vuole collegarsi con un server dice al sistema operativo di creare un socket  s ,poi dice sempre al sistema operativo di collegare questa estremità s  con il server che avrà un certo TCP  e quindi si crea un tubo che va da s al welcoming socket nel quale il server invia una richiesta di connessione, ma il client è già connesso appunto da questo tubo con il server quindi perchè chiede una richiesta di connessione casomai  dovrebbe chiedere una richiesta di invio dati? 

evidenzio in rosso le imprecisioni solo ed esclusivamente a fine didattico.

"il server ha un certo indirizzo TCP";

il server non invia nessuna richiesta di connessione; è il client che invia richieste di connessione:

"perché chiede una richiesta": non capisco chi sia il soggetto della frase; è il client o il server? inoltre, nessuno chiede una richiesta; al massimo invia una richiesta.

detto questo, non sono certo di avere capito la domanda; credo che se uno cancella dalla propria testa la slide sopra indicata allora il dubbio alla radice di questa domanda sparisce;

cerco di spiegare in modo diverso lo stesso concetto.

noi ci troviamo al di sopra del livello TCP (cioè del sistema operativo, che tra il miliardo di cose che fa, implementa anche TCP); pertanto noi vediamo solo come si usa TCP, non come è implementato e funziona internamente; questo è il concetto fondamentale;

da ciò discende che noi vediamo solo le procedure con cui si interagisce con TCP (socket, bind, listen, etc); non vediamo come sono implementate queste procedure;

da ciò discende che noi non sappiamo come faccia il sistema operativo del client a creare una connessione TCP con il sistema operativo del server. sappiamo solo che il server ha eseguito socket, poi bind, listen e accept sul welcoming socket, poi si sveglia ed ha disposizione anche un communication socket; mentre il client ha eseguito socket, poi connect specificando l'indirizzo TCP del server; basta. non sappiamo altro.

quindi quando diciamo che "il client invia una richiesta al server", stiamo solo facendo una descrizione molto superficiale ed approssimata di ciò che probabilmente accade; ma è importante notare che questa descrizione non è necessaria per capire le caratteristiche del servizio TCP (cioè, ancora, come si usa; come è realizzato non lo sappiamo).

2) il sistema operativo del server una volta  ricevuta la richiesta crea un nuovo socket s2  e quindi un nuovo tubo e lo collega con s  corretto?

si

3) ma quindi anche il sistema operativo del server può aprire una connessione dopo la richiesta di connessione da parte del client, cioè non è solo il sistema operativo del client ma anche quello del server  che apre una connessione corretto?

​si​. apre una connessione quando il processo server sta eseguendo accept e un qualche processo client in giro per il mondo sta eseguendo connect verso l'indirizzo TCP di quel processo server.

4) SOCKET= ESTREMITA' DI CONNESSIONE = PORTA ?

socket = estremità di connessione è vero;

socket = porta è falso, esattamente come è falso dire che calzino = pera; sono oggetti di tipo diverso, non ha senso chiedersi se sono uguali;

(osservazione didattica e non polemica) questa domanda è un esempio illuminante di quanto ho cercato di dire a lezione: è fondamentale abituarsi ad associare ad ogni entità il suo tipo; è necessario farlo sempre ed istintivamente;

cerco di rielaborare la domanda; intanto che cos'è una "porta"? noi abbiamo parlato di socket, connessioni, estremità di connessioni, port number; non abbiamo mai parlato di porta; se io ho parlato qualche volta di porta allora ho sbagliato;

le porte non esistono; esistono i numeri di porta; so che la faccenda è strana e controintuitiva, ma non sono io ad avere scelto la terminologia; peraltro, vi ho già fatto notare che ci sono i socket ma non ci sono i plug (cioè ci sono le prese ma non ci sono le spine);

talvolta, quando si parla in modo informale e gergale si usa il termine "porta" come sinonimo di "numero di porta"; visto che stiamo cercando di imparare, è importantissimo usare un linguaggio preciso (quindi non porta ma port number); quando uno ha imparato può permettersi di usare un linguaggio ambiguo, perché nella propria testa uno ha chiara la differenza (si spera); ma quando uno sta imparando, l'uso di un linguaggio ambiguo può danneggiare la comprensione ed introdurre ambiguità anche nella testa;

"è in ascolto sulla porta 80"; significa "è in attesa di richieste di apertura di connessione sul port number 80"; "è connesso sulla porta 80" significa "è connesso sul numero di porta (locale o remoto, dipende da cosa si sta dicendo) 80";