Newsgroup: it.comp.lang.c
Titolo: Rispetto coda FIFO connessioni pendenti in listen

1) Rispetto della coda FIFO delle connessioni pendenti in listen (socket
unix).
Obiettivo minimo di tutti i progettini client-server e` quello di
garantire l'accettazione del servizio a piu` client che si connettono in
rapida sequenza allo stesso server.
Cosa che io ho provato nel seguente modo: gia` in funzione con 4 o 5
client, preparo 4 shell col comando di lancio dei client belle e pronti
e poi li lancio in velocita` uno dietro l'altro.
Ora nelle mie prove a casa con Linux non ho mai avuto problemi, tutti i
client lanciati andavano ad inserirsi seguendo la STESSA sequenza con
cui li avevo lanciati.
Ma quando ho voluto ripetere la prova qua al lavoro (macchine Sun ma non
chiedetemi di piu`) ho assistito a un fenomeno diverso, l'ordine di
inserimento dei client che hanno fatto la connect e` abbastanza casuale,
spesso inverso a quanto mi aspetto (ultimo che si connette --> primo che
viene accettato). Un collega banalizza il tutto dicendomi che il nostro
s.o. non garantisce la gestione FIFO sulla coda di listen, basta
scrivere codice che non si aspetti un fedele FIFO e non ci sono
problemi.
Mi sembra cosi` strana la cosa?
E` possibile? Ed e` possibile fare in modo che cio` non avvenga a
prescindere della politica della coda di listen?
Grazie e saluti
-- 
Giuseppe R.
E-mail: mailto:
giuseppe...@SPAMnetit.alcatel.it
--
Posted from 
ns.alcanet.it
 [194.243.74.35] 
via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 prescindere della politica della coda di listen?
Si, e' possibile:
Lanci un client, aspetti che si connetta, e poi lanci il successivo,
ecc ecc.
Ciao, Andrea
-- 
 _     /°#     ----------------+--------------
°  \  /        Andrea          | arimicci @@
   |++~|            Rimicci    |  aritaly. com
    \ /  --------- OS/2 V5 "Phoenix" ----------
     |   C,C++,cgi,miva,Java,php Developer and
    _|_  OS/2 Warp Server for E-business admin

 prescindere della politica della coda di listen?
Premesso che il post e' altamente OT,quindi per problematiche concernenti il
mondo unix ci
si rivolga a NG appropiati.
Il fatto e' che lo standard  come daltronde ci si aspetta prevede una
gestione FIFO delle connessioni
accettate,quindi il primo client che arriva dovrebbe essere il primo ad
avere la connessione al server,ma
un bug che persiste ancora in alcune Berkeley-derived-implementation vedere
SunOS 4.1.3 implementava
tale gestione in maniera LIFO.
NB: Dovresti notare che anche se il client eseguito prima,viene in realta'
connesso non per primo,la sua ephemeral port
e' la piu' bassa, in quanto la sua connessione e' stata accetta per prima
dal server ma connessa per ultima.
Ivan Molella

 perche', ti consiglio una buona lettura sui sistemi multitasking.
la buona lettura fa sempre comodo. Rimango scettico per il fatto che una
gestione FIFO mi sembra la piu` corretta e anche semplice da applicare,
non riesco a spiegarmi perche` adottare una politica diversa (LIFO) o
addirittura casuale.
Grazie e ciao
-- 
Giuseppe R.
E-mail: mailto:
giuseppe...@SPAMnetit.alcatel.it
--


 dal server ma connessa per ultima.
Ephemeral??? 
Cioe` la porta su cui il server gestisce la read/write col client? In
effetti ho fatto la prova stampando a video i numeri di porta dei client
e risulta quel che dici. Si puo` vedere anche con la netstat?
Grazie


 Ephemeral???
Ephemeral port e' la porta cheil kernel assegna al client.
Ephemeral in quanto non appartenente al range delle Well-Known-port che vanno
dalla porta 1 fino alla 1024.
In genere il kernel assegna al client la prima porta libera al di fuori di questo
range.
Con netstat puoi vedere lo stato dei socket ma non ti accorgi del processo a cui
e' assegnata la porta.
Il  debug  sull'accettazione delle connessioni lo puoi fare solo facendo il debug
ai tuoi processi come mi sembra che hai gia' fatto.
Ivan Molella

Mi dispiace ma dove postare?
Se ti  va bene in inglese:
comp.protocols.tcp-ip,
comp.unix.programmer.
Il secondo in particolare, in questo caso.
F.

 comp.unix.programmer.
Argghh!!!
Purtroppo l'inglese e` un ostacolo in piu`... dover prima tradurre i
miei testi in maniera comprensibile e poi ripetere il processo inverso
per le risposte diventa un impresa ardua!
Pero` conto di fare un salto sui ng che mi segnali e magari sfruttarli
in futuro. Grazie
