Calcolo degli argomenti nel comando PORT del FTP

[dades]

Sto creando un client ftp.
Ora sto implementando il comando PORT.
Esso come argomento possiede: x1.x2.x3.x4.p1.p2.
Le x sono le componenti dell'indirizzo ip e p1 e p2 identificano la porta.
La porta si calcola p1*256+p2.
Il problema è come calcolo p1 e p2 data una porta???
Qualcuno può aiutarmi??
Qualcuna sa perchè si usa questo metodo??

[dades]

Ho capito come funziona.
Si divide il numero della porta per 256. Si tiene il numero intero. Questo è p1.
Mentre il resto della divisione è p2.
Ma non riesco a capire perchè si sono inventati sto metodo per trasferire il numero di porta.
Non potevano fare semplicemente PORT numPort??
Qualcuno sa dirmi il perchè??

[MItaly]

Boh, il concetto di fondo è di spezzare indirizzo e porta in campi da 8 bit ciascuno, non so che utilità pratica possa avere.
Rispetto alla divisione comunque un metodo più efficiente e semanticamente corretto è l'uso degli operatori bitwise, su cui però non ti so dare indicazioni più precise dal momento che non hai specificato il linguaggio di riferimento.

[billiejoex]

Non l'ho mai capito manco io.
Il comando PORT risale all'RFC-959, se non da prima ancora, per cui trovare le ragioni di determinate decisioni oggi non è proprio immediato.
Col senno di poi si può comunque dire che come decisione fu sbagliata in quanto nei comandi EPRT e EPSV, che sono molto più recenti, il numero di porta è un normale intero su cui non si deve applicare alcuna operazione aritmetica.

[billiejoex]

Giusto per la cronaca aggiungo che stai ovviamente reinventando l'acqua calda in quanto, come probabilmente gia saprai, un client FTP ce l'hai gia nella libreria standard di Python.

[dades]

Sto creando un ftp client per gli esami. Lo so che ci sono a disposizione le librerie con un qualsiasi linguaggio di programmazione.
Il prob è che mi piacerebbe dare una spiegazione sul perchè di questa suddivisione. Sicuramente almeno un prof(o info o sistemi) mi chiederà: "ma perchè questa suddivisione, non si può spedire direttamente il numero di porta??"

[LeleFT]

Dato che il protocollo FTP risale al 1971, quando anche un solo bit costava caro, probabilmente era stato pensato di utilizzare la comunissima notazione posizionale tipica del nostro sistema di numerazione. Dato che il numero di porta può essere un qualunque numero intero compreso fra 0 e 65536 (lascio a te capire perchè 65536), esso va rappresentato su due byte (unsigned).

Dato che la base di numerazione del sistema informatico è il byte (che ha valori decimali da 0 a 255 = 256 valori in tutto), non vedo dove sia il problema. In un qualunque sistema di numerazione posizionale, il valore numerico rappresentato su due simboli si calcola in questo modo (dato il numero "AB", dove A e B sono due simboli del sistema):

B * (base ^ 0) + A * (base ^ 1)

Un esempio nel sistema decimale (base 10): il numero "45" rappresenta il valore:

5 * (10 ^ 0) + 4 * (10 ^ 1) = 45

Se fossimo in un sistema che utilizza il byte come base (quindi il valore 256), avremmo che "45" rappresenta (assumendo che 4 e 5 non siano i caratteri ASCII ma i valori):

5 * (256 ^ 0) + 4 * (256 ^ 1) = 1029

Tutto qui.


Ciao.

[MItaly]

Originariamente inviato da LeleFT
Dato che il protocollo FTP risale al 1971, quando anche un solo bit costava caro

Appunto: perché allora perdere tempo a spezzare il numero di porta, il che tra l'altro allunga la richiesta? Rispetto ad una cosa tipo

PORT 192.168.0.1:21

viene preferita una notazione più lunga in qualunque circostanza

PORT 192,168,0,1,0,21

visto che viene impiegato un byte per la virgola e almeno un byte per lo spezzone degli 8 bit più significativi, anche se non serve. Io questo non mi spiego.
Comunque, forse sarebbe meglio aggiungere al titolo di questo thread un tag [Aria fritta], così si capisce che stiamo discutendo del sesso degli angeli.

[billiejoex]

Originariamente inviato da dades
Sto creando un ftp client per gli esami. Lo so che ci sono a disposizione le librerie con un qualsiasi linguaggio di programmazione.
Il prob è che mi piacerebbe dare una spiegazione sul perchè di questa suddivisione. Sicuramente almeno un prof(o info o sistemi) mi chiederà: "ma perchè questa suddivisione, non si può spedire direttamente il numero di porta??"

A una domanda del genere io mi limiterei a rispondere: "questo è quanto dichiara l'RFC" e fine.
Per il resto sono solo chiacchiere da bar.
L'RFC è li da decenni ed è cosi piena di imprecisioni, contraddizioni, errori e quant'altro che questo "dettaglio" della porta è davvero il meno, ti assicuro.
Ci potrei scrivere un paper sulle indecenze della 959. =)

[LeleFT]

Originariamente inviato da MItaly
Appunto: perché allora perdere tempo a spezzare il numero di porta, il che tra l'altro allunga la richiesta? Rispetto ad una cosa tipo

PORT 192.168.0.1:21

viene preferita una notazione più lunga in qualunque circostanza

PORT 192,168,0,1,0,21

visto che viene impiegato un byte per la virgola e almeno un byte per lo spezzone degli 8 bit più significativi, anche se non serve. Io questo non mi spiego.
Comunque, forse sarebbe meglio aggiungere al titolo di questo thread un tag [Aria fritta], così si capisce che stiamo discutendo del sesso degli angeli.

Probabilmente lo hanno fatto per maggiore leggibilità da parte dei programmatori. Il programmatore sa che verrà inviata una stringa di 6 byte (4 per l'indirizzo, 2 per la porta). I punti (o le virgole) servono solo a separare i byte... questo evita di dover riconvertire gli ultimi 2 byte in un numero decimale se si ha già la rappresentazione su 6 byte.

Per il resto, direi che effettivamente non si tratta di un problema di programmazione, ma va lasciata aperta la discussione in quanto legata ad un protocollo (FTP) che è fortemente connesso con essa.


Ciao.