Newsgroup: it.comp.sicurezza.varie
Titolo: OT : chat lento

Salve a tutti,
scusate l'ot, ho costruito un prg che permette a N utenti di chattare,
stasera l'ho provato ma risulta: essere veloce nella spedizione dal
mio computer a quello del mio amico / essere molto lento nella spedizione
dei dati da quello del mio amico al mio (spesso i suoi dati non arrivano
nemmeno).
tra i nostri due computer ci sono solo altri 5 computer (tracert), il ping
e' rapidissimo, la connessione usata dal chat server e' tcp (abbiamo
provato prima la porta 29999 e poi una standard 80 con uguali risultati)
E' possibile che il tcp decida un percorso molto diverso da quello
visualizzato dal tracert ? (molto piu' lungo/lento)
E' possibile chiedere a W95 il percorso di una connessione tcp aperta
(uso direttamente le api per i socket) ?
Eventualmente sapete dirmi su quale ng postare questa domanda senza
essere ot ? (su alt.spippolatori non vedo niente, nemmeno un msg)
Ciao
Carlo

 Su alt.spippolatori non vedi messaggi perche' l'ho aperto pensando che me
lo attivassero anche su interbusiness .. invece solo le anime pie della tin
lo hanno preso! ;-)
   E dato che molti per collegarsi alla tin devono andare in interrurbana  o
rischiare la salute attaccandosi al telefono dell'inquilino di sotto ..  si
continua su cough.cough!
 Se mi mandi mandi per email deu righe sul tuo prog.. e se funziona bene ..
lo mettiamo in archivio e lo usiamo! .. cosi' si guarda anche se puo' essere
migliorato come chiedevi tu.

 nemmeno).
Se ho ben capito sul tuo computer gira il "server" e su quello
del tuo amico il "client".
Se e' cosi':
a) Windows non e' un sistema operativo di rete, nemmeno NT,
   non e' progettato per gestire applicazioni "impegnative"
   con molti socket aperti. [Abbiamo tentato in passato un
   port su NT di ircu, il server irc di Undernet, su Linux/BSD
   un 486 si porta 3-400 utenti tranquilli, su Windows NT
   la stessa macchina va in palla con 30 utenti, stesso codice].
b) Dipendera' probabilmente da come selezioni gli fd (socket)
   da cui leggere/scrivere i dati, su BSD c'e' una cosa che si
   chiama select(), su SystemV un cosa che si chiama poll()
   che fa lo stesso servizio, su NT non so, trattasi di una
   chiamata di sistema alla quale dici "Vorrei leggere sui
   socket A o B o C o D, oppure scrivere sui socket X o Y o Z"
   e qualla risponde "Ok.. i socket A e B hanno dei dati da 
   farti leggere, il socket Y e' pronto per accettare altri dati
   in scrittura". Se tenti di leggere da un socket che non ha dati
   e sei in BLOCKING I/O il server si ferma ad aspettare quel
   socket anche se magari un altro ha dati pronti da elaborare...
c) Non credo che c'entri il routing, eventualmente prova una
   passive open telnet da un lato e una active open dall'altro,
   oppure semplicemente a trasferire dei dati da un lato all'altro
   e vice versa con FTP, comunque usando solo codice "consolidato"
   e non cose scritte in casa, se il problema della differenza di
   performance in una direzione si presenta anche e in modo
   vistoso su un socket aperto con software "noti" allora,
   e solo allora, e' ipotizzabile un problema di routing.
   Comunque un quel caso un banale traceroute in una direzione
   e nell'altra ti dice tutto. TCP non decide un percorso dei
   pacchetti, lo decide IP con la stessa strategia che si tratti
   di TCP, UDP, ICMP o altro, quindi se i due percorsi sono diversi
   nelle due direzioni (copsa del resto possibile) due traceroute
   dai due lati te lo dicono.
Consiglierei it.comp.lang.* dove '*' e' il linguaggio
di programmazione in cui e' scritta la "cosa", per me il
problema e' li e non a livello di network.
it.comp.sicurezza.varie e' completamente offtopic... al massimo
avrei capito it.comp.reti.ip-admin :)
Ciao,
-- 
Andrea

avrei capito it.comp.reti.ip-admin :)
Provero' anche questo...
Ciao e grazie   ;-)
Carlo