Newsgroup: it.lavoro.professioni.webmaster
Titolo: Leggere pacchetti in internet, va bene 1460 byte?

Un server apre connessioni (socket) verso altri server, scrive della 
roba e legge della roba.
E' corretto leggere gruppi di byte da 1460 byte?
Dovrebbe essere la quantitï¿œ di dati trasportati da un singolo pacchetto tcp.
Vorrei leggere la quantitï¿œ minima indispensabile e poi chiudere la 
connessione tcp col fine di ridurre al minimo la ricezione di pacchetti 
e risparmiare banda.
Se leggessi gruppi di byte da 512 byte risparmierei banda?
Secondo i miei calcoli no, perchï¿œ i 512 byte arrivederebbero comunque da 
un pacchetto tcp contenente 1460 byte.
Ma chiedo a voi conferme, smentite, pareri. Grazie.

 Ma chiedo a voi conferme, smentite, pareri. Grazie.
Non c'ï¿œ una lettura "migliore" di altre: dipende da che tipo di 
pacchetti ricevi e trasmetti.
Curiositï¿œ mia: hai problemi di banda cosï¿œ pesanti da dover ricorrere ad 
una "taratura" cosï¿œ spinta dei socket?
Ciao,
Pablo


Fuori da ogni polemica, cosi appena per curiositï¿œ.... come mai questo 
interesse cosi specfico? Ormai i problemi di traffico sono superati
Io capisco per i cellulari, ma in ogni caso indipendentemente dalla 
dimensione del pacchetto... (se N ï¿œ la sua dimensione) al massimo ciï¿œ che 
risparmi sono N-1 byte.
Poichï¿œ la dimensione del pacchetto ï¿œ trascurabile siamo nell'ordine di byte, 
il tuo risparmio di traffico ï¿œ insignificante.
-- 
http://www.blueware.it
bluewarewebstudio (skype) 

 Dovrebbe essere la quantità di dati trasportati da un singolo pacchetto tcp.
Non è vero, non è mica fisso, dipende dalla qualità della connessione.
Il concetto dell'uso di TCP è proprio quello di offrire la comunicazione 
alle applicazioni facendo in modo che queste possano ignorare i livelli 
inferiori.
L'apertura e la chiusura delle connessioni costa comunque in termini di 
scambio di pacchetti, devi valutare se è più conveniente lasciare aperta 
la socket senza traffico (c'è heartbeat in TCP?) o chiuderla e riaprirla 
all'occorrenza.

 una "taratura" cosï¿œ spinta dei socket?
No ma mi piace ottimizzare. :)

 di una connessione http restituiti da un server web?
Non c'e` una dimensione fissa, dipende da molti fattori. Possono anche 
partire da 1500 byte e poi venire spezzati da router, gateway, ecc.
 
Bye.

e risparmiare banda.
Somiglia molto ad una soluzione giusta per il problema sbagliato :-)
Cos'e' che vuoi fare ESATTAMENTE?
Perche' a seconda di cos'e' e _come_ occorre reagire alla "roba" che
leggi o scrivi, le cose cambiano.
Quante connessioni fai, e come disposte?
Senza sapere questo, "Vai libero, 1460 byte va benissimo!" ha uguali
probabilita' di essere corretta di "Usa 536" o "Fregatene, manda con
la dimensione predefinita di sistema".
Leonardo
-- 
The cock doth craw, the day doth daw,
the channerin' worm doth chide:
gin we be mist oot o' oor place,
a sair pain we maun bide.

la socket senza traffico (c'� heartbeat in TCP?)
Se lo chiedi con SO_KEEPALIVE, si'. Ma e' un battito molto lento, 7200
secondi di default (e sostanzialmente tocca lasciare il default).
Se leggi RFC1122 (4.2.3.6) ti rendi conto come tutta l'implementazione
abbia un'elevatissima probabilita' di essere distinguibile da un sacco
di guano di pterodattilo solo verificando la presenza di un sacco, con
il timeout lungo ed il default ad OFF che si incaricano di impedire il
collasso della civilta' occidentale.
Poi si puo' parlare dei sovrastrati creativi courtesy of MS, specie di
quelli del Remote Desktop (dove il probe e' sapientente reso superfluo
dalla presenza dell'orologino nella traybar, ringraziando a PADREPIO).
All in all - suggerirei di NON toccare quella roba se non con pertiche
da bottinaro, e per la stessa ragione.
Leonardo pessimista


 di una connessione http restituiti da un server web?
La connessione HTTP non è a pacchetti, però trovi pacchetti ai livelli 
più bassi fisico, di rete e di trasporto. 
Secondo me è un'ottimizzazione che non ha senso perché non ottimizza 
nulla.

 
Ma che pessimista solo qualunquista!
1460 va benissimo com 1500 ma non lo sai bene se non usi tcp 
optimizer....  che poi dice uno dei due valori!

 No ma mi piace ottimizzare. :)
Prima di ottimizzare qualcosa uno dovrebbe capire un minimo di quello di 
cui sta parlando...
Per rispondere anche ad altri l'mtu massimo non ï¿œ di 1500 byte (ci sono 
i jumbo frame in lan).
E comunque non ï¿œ che se tu fai una read di 50 byte il sistema operativo 
fa passare sulla rete solo 50 byte. Te apri il socket e volendo il 
server ti inizia a sparare dati, si ferma quando ha riempito il buffer 
interno del s.o. quindi non hai tutto sto controllo sul traffico.

 optimizer....  che poi dice uno dei due valori!
Ecco, per es.: tu sai ESATTAMENTE cosa fa TCP Optimizer -- e perche' deve
essere preso con un grosso grano di sale? O ti limiti a cliccarci a caso,
e se non funzioni bofonchi "Che programma di merda" e ne provi un altro?
Leonardo


 e se non funzioni bofonchi "Che programma di merda" e ne provi un altro?
Non vedo particolari errori sintattici o grammaticali in quella frase, 
ho forti dubbi riesca ad inanellare ben 4 parole senza sembrare animal 
dei muppet.
  ngw
-- 
Nicholas Wieland (ngw)
Zooppa CTO
911 Western Avenue, Suite 420
Seattle, WA  98104  US

 
Esatto, infatti dopo il primo utilizzo non l'ho pi� cagato.
Ora tutto gira talmente velocmente (almeno a me e comprese le palle) che 
quei valori hanno un importanza relativa.

 
Si si certo! f/u

quei valori hanno un importanza relativa.
Be', e' un piacere avere discussioni di s� alato livello tecnico.
Alla prossima, eh?
