| Precedente :: Successivo |
| Autore |
Messaggio |
Matteo Sgalaberni
Ospite
|
 Inviato: Ven 06 Lug 2007 18:29 Oggetto: udp socket, packet loss |
 |
|
Ciao $amici,
ho la seguente situazione:
- server python A che ha in listen un socket UDP.
- client B che apre in un istante 300 thread che fanno una connect al
server e pushano ognuno un pacchetto UDP. totale 300 pacchetti.
su server A a volte arrivano 300 pacchetti regolarmente, ma a volte
ne mancano 1-2, una ventina... e così via...
(il pacchetto che mando può assumere dimensioni variabili di max 15byte,
quindi mado al max in una esecuzione di cliente
15data+8header=23byte*300=6900byte di dati)
Considerando il fatto che server non fa elaborazione ma legge il socket
e mi statistica solo il risultato... qualcuno mi spiega perchè ho sta
perdita? E' perchè è UDP e quando si riempie un qualche buffer che non
o di quanto è su server(app o kernel?) allora scarta pacchetti?
come posso ovviare il problema tenendo presente che:
- non posso usare tcp
- non posso implementare a livello applicativo un meccanismo di
acknowledge/controllo di errore/packet loss del pacchetto, il client
deve pushare e poi fare altro, non ha tempo di fare altre cose...
Ciao e grazie:)
M |
|
| Top |
|
 |
Guido Bolognesi [ Zen ]
Ospite
|
| Inviato: Ven 06 Lug 2007 19:44 Oggetto: udp socket, packet loss |
|
|
On Fri, Jul 06, 2007 at 07:30:12PM +0200, Matteo Sgalaberni wrote:
ciao $amico,
| Citazione: | - server python A che ha in listen un socket UDP.
- client B che apre in un istante 300 thread che fanno una connect al
server e pushano ognuno un pacchetto UDP. totale 300 pacchetti.
|
#define "un istante"
| Citazione: | su server A a volte arrivano 300 pacchetti regolarmente, ma a volte
ne mancano 1-2, una ventina... e cos? via...
|
Mai successo che ne manchino 300, suppongo.
Quanti te ne perdi al massimo?
| Citazione: | 15data+8header=23byte*300=6900byte di dati)
|
non credo sia un problema di banda. Ne` (ipotizzo) di latenza.
| Citazione: | perdita? E' perch? ? UDP e quando si riempie un qualche buffer che non
o di quanto ? su server(app o kernel?) allora scarta pacchetti?
|
Chiedo: come funziona in python il listen sulle socket udp?
Lo Stevens[1] mi dice che solitamente i server UDP sono iterativi,
e ad ogni porta il S.O. assegna un buffer di dimensione finita.
Forse, come dicevi tu, lo riempi con il burst di pacchetti.
Giusto per capirci, ho riesumato una roba cosi` (mi perdonino
i programmatori in lista...)
====
from socket import *
host = "127.0.0.1"
port = 5555
buf = 1024
addr = (host,port)
UDPSock = socket(AF_INET,SOCK_DGRAM)
UDPSock.bind(addr)
while 1:
data,addr = UDPSock.recvfrom(buf)
if not data:
break
else:
print data
===
se allarghi buf di potenze di 2, cosa succede?
| Citazione: | come posso ovviare il problema tenendo presente che:
|
Se tu riscrivessi il listener in C e poi salvassi i dati
da qualche parte, per poi processarli con calma con il pitone?
[1] Ho dato uno sguardo ad Advanced Programming in the UNIX Env,
ma non ne parla. Qui cito il TCP/IP Ill. v.1 (pg 163).
ciau!
_________________
guido . zen@xxxxxx.xyz . skype://zenmobile |
|
| Top |
|
|
Roberto Bettazzoni
Ospite
|
| Inviato: Sab 07 Lug 2007 02:15 Oggetto: udp socket, packet loss |
|
|
Ciao,
lo so che sono malato, ma quando vedo del codice è + forte di me
Ho avuto anch'io problemi con l'UDP, perdevamo dei pezzi per strada.
Ma nel mio caso era dovuto al protocollo, siamo stati costretti a
passare a TCP. (con mia grande gioia)
Guido Bolognesi [ Zen ] ha scritto:
...
| Citazione: |
se allarghi buf di potenze di 2, cosa succede?
|
Non sono sicuro al 100%, quello che dico si basa su "conoscenza empirica".
Con messaggi brevi, nulla.
Il "buffer" a cui fai riferimento è la quantità di byte attesi,
la dimensione massima della stringa ritornata del metodo recv (o similari).
Nel caso di socket bloccanti l'esecuzione si blocca in attesa di tutti i byte
del messaggio oppure del termine messaggio.
I buffer "veri" sono altri.
Ho preso il codice di zen ed ho fatto 2 o 3 modifiche per fare delle prove
(in allegato trovate il codice).
Dallo smoke test, a me funziona sempre, 0 pacchetti persi.
Ma sono su una comodissima LAN, con solo 4 PC e tutti piuttosto "robustini"
non credo che sia un test valido.
I miei 2 spiccioli,
TaZ
=================== ATTACHMENT #2 ===================
from socket import *
buf = 16
addr = ("", 5555)
UDPSock = socket(AF_INET, SOCK_DGRAM)
UDPSock.bind(addr)
arrivati= []
while 1:
data = UDPSock.recv(buf)
if not data:
break
else:
if data[0] == '-':
print " ".join(arrivati)
print "** totale %d messaggi **" % len(arrivati)
print data
arrivati= []
else:
arrivati.append(data)
=================== ATTACHMENT END =================== |
|
| Top |
|
|
Davide Alberani
Registrato: 04/04/07 08:47
Messaggi: 953
|
| Inviato: Sab 07 Lug 2007 18:14 Oggetto: udp socket, packet loss |
|
|
On Jul 07, Roberto Bettazzoni <ml@xxxxxx.xyz> wrote:
| Citazione: | lo so che sono malato, ma quando vedo del codice è + forte di me
|
Gh. :-)
| Citazione: | Ho preso il codice di zen ed ho fatto 2 o 3 modifiche per fare
delle prove (in allegato trovate il codice).
Dallo smoke test, a me funziona sempre, 0 pacchetti persi.
|
Su localhost, macchina lentuccia ed indaffarata, col tuo codice ho
comportamenti buffi aumentando il numero di thread, ricevendo
una eccezione (python 2.4):
Traceback (most recent call last):
File "./c", line 27, in ? # l'ho modificato, il nr di riga non fa testo.
for c in clienti: c.start()
File "/usr/lib/python2.4/threading.py", line 416, in start
_start_new_thread(self.__bootstrap, ())
thread.error: can't start new thread
Al salire del numero, le possibilita` di beccarsi l'eccezione
crescono (diventando molto probabile sopra i 600 o 700 thread).
Non saprei a chi dare la colpa; aggiungendo un time.sleep(0.0001)
(per dire) dopo c.start() tutto va sempre (?) bene, ma e` chiaro che
da qualche parte qualcosa di orrendo sta accadendo, e non ci si
puo` fare affidamento. :-)
Non ho limit particolari e /proc/sys/kernel/threads-max e` a 8191;
non mi sembra ci siano altri limiti a livello di sistema, ed il
fatto che lo faccia solo ad intemittenza mi puzza di Roba Che Si
Imputtanisce(tm) sotto carico.
Mumble, mumble...
Per il Buon Sgala:
- non e` che eccedi di bonta` e trappi tutte le eccezioni che ti
capitano a mano, nascondendo dunque errori nel lancio di alcuni
dei thread?
- sei mica sotto Windows? Dovrebbe - a dio piacendo - farlo solo
con messaggi molto lunghi, ma mi risulta che socket.send() possa
decidere di mandare solo una parte del messaggio (socket.send
ritorna il numero di bytes inviati).
HTH,
_________________
Davide Alberani <da@xxxxxx.xyz> [PGP KeyID: 0x465BFD47]
http://erlug.linux.it/~da/ |
|
| Top |
|
|
tannoiser
Registrato: 02/04/07 10:06
Messaggi: 621
|
| Inviato: Sab 07 Lug 2007 20:33 Oggetto: udp socket, packet loss |
|
|
* sabato 07 luglio 2007, alle 19:15, Davide Alberani scrive:
| Citazione: | Su localhost, macchina lentuccia ed indaffarata, col tuo codice ho
comportamenti buffi aumentando il numero di thread, ricevendo
una eccezione (python 2.4):
Traceback (most recent call last):
File "./c", line 27, in ? # l'ho modificato, il nr di riga non fa testo.
for c in clienti: c.start()
File "/usr/lib/python2.4/threading.py", line 416, in start
_start_new_thread(self.__bootstrap, ())
thread.error: can't start new thread
Al salire del numero, le possibilita` di beccarsi l'eccezione
crescono (diventando molto probabile sopra i 600 o 700 thread).
|
<>
| Citazione: | - non e` che eccedi di bonta` e trappi tutte le eccezioni che ti
capitano a mano, nascondendo dunque errori nel lancio di alcuni
dei thread?
- sei mica sotto Windows? Dovrebbe - a dio piacendo - farlo solo
con messaggi molto lunghi, ma mi risulta che socket.send() possa
decidere di mandare solo una parte del messaggio (socket.send
ritorna il numero di bytes inviati).
|
Non e` che python succhia?
/me e il rasoio di Occam ;) <beg>
_________________
Maurizio - Tannoiser - Lemmo
Founder Member of ERLUG http://erlug.linux.it
-------------------------------------------------------------------------------
BOFH excuse #311:
transient bus protocol violation |
|
| Top |
|
|
Davide Alberani
Registrato: 04/04/07 08:47
Messaggi: 953
|
| Inviato: Dom 08 Lug 2007 09:34 Oggetto: udp socket, packet loss |
|
|
On Jul 07, Maurizio Lemmo - Tannoiser <tannoiser@xxxxxx.xyz> wrote:
| Citazione: | Non e` che python succhia?
|
Po' esse, ma son troppo impegnato a capire come mai uno script ruby
mi schianta amarok ogni 3x2, per controllare. <g>
| Citazione: | /me e il rasoio di Occam ;) <beg>
|
/me ed una lunga giornata. ;-)
_________________
Davide Alberani <da@xxxxxx.xyz> [PGP KeyID: 0x465BFD47]
http://erlug.linux.it/~da/ |
|
| Top |
|
|
Roberto Bettazzoni
Ospite
|
| Inviato: Dom 08 Lug 2007 18:03 Oggetto: udp socket, packet loss |
|
|
Davide Alberani ha scritto:
...
| Citazione: | Su localhost, macchina lentuccia ed indaffarata, col tuo codice ho
comportamenti buffi aumentando il numero di thread, ricevendo
una eccezione (python 2.4):
|
...
Uhmmmm ... molto strano.
a me è capitato solo lanciandolo in debug mode da dentro l'IDE.
... ma questo me lo aspetto: non ho fiducia nel "debug mode"
quando si parla di m-threading.
Visto che in passato ho sofferto molto a causa del m-threading e che
ho un po' di tempo libero, ho deciso di "togliermi qualche sassolino
dalla scarpa"
Avviso ai naviganti:
questa è una sclerata su codice masochistico.
procedete a Vs. rischio e pericolo. You were warned :-)
Ho provato lo stesso codice di prima con 100.000 thread su diversi O.S.
tutti con Python 2.4.3
- sotto Ubuntu 6.06 su un P3 500Mhz con 512 Mb ram
ci mette 1 minuto, CPU fissa al 100%, occupa circa 100 Mb
0 problemi
- sotto Winzoz XP su un P4 3 Ghz con 1 Gb ram
ci mette circa 3 minuti, CPU al 100%, occupa circa 100 Mb
Mia "sensazione" dovuta all'osservazione delle "risorse di sistema":
mi pare che utilizzi pochi thread "veri" e sequenzializzi.
Questa "sensazione" è suffragata da:
1) i tempi: un PC molto + veloce ci mette 3 volte di +
2) un sguardo all'ordine dei pacchetti UDP arrivati sul server.
Sono tutti "numericamente vicini", a occhio lo scarto massimo è delle decine,
con linux c'erano casi con discordanze di diverse centinaia
Ok, a parità di logica, linux è molto migliore di winzoz su tutto quello che
riguarda le socket (e non solo), ma sui thread il prodotto di seattle dovrebbe
cavarsela egregiamente (almeno questa è la mia esperienza).
E poi ... 3 volte di + e sequenziale? a tutto c'è un limite.
Uhmmmmm ... qualcosa tocca.
- con Mac OSX 10.4 su un Mac Book Intel Core Duo 2Ghz, 2 Gb ram
ci mette più di 50 minuti (!), CPU al 4%
i messaggi arrivano perfettamente ordinati
... ma stiamo scherzando???
Bloccando l'esecuzione in qualsiasi momento si scopre l'arcano
"""
File "clientUDP.py", line 23, in ?
for c in clienti: c.start()
File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/threading.py", line 418, in start
_sleep(0.000001) # 1 usec, to let the thread run (Solaris hack)
"""
Le librerie pitoniche del Mac introducono uno sleep sull'avvio del thread!
Quindi, mentre il thread X "parte" il sistema si fa una penichella,
(e di _almeno_ un microsecondo, la sleep pitonica non è precisissima),
così che, al risveglio, quando lancia il thread X+1, il thread X è già storia.
Questo giustifica alcune "cose molto strane" che vedevo sul mac.
Non ho parole ... ho solo voglia di spaccare in due una mela!
Maurizio Lemmo - Tannoiser ha scritto:
...
| Citazione: | Non e` che python succhia?
|
si, per fare cose del genere posso essere d'accordo.
Comunque,
nella "vita reale" non mi verrebbe mai in mente di aprire tanti thread con
il serpide sotto qualsiasi sistema operativo.
Anche perché le funzioni "select" e "poll" (solo *nix) le hanno fatte apposta.
Inoltre tieni conto della "perversione intrinseca" al codice che ho mandato:
apre N thread all'unico scopo di utilizzare (sincronizzarsi) su un'unica
risorsa, detenuta dal s.o. e che, per sua natura, è sequenziale.
Se qualcuno scrive un codice del genere in un programma vero deve essere
crocifisso in sala mensa, a monito per le genti.
... ma in un raffinato cenacolo di masochisti, direi che ha un suo perché
:-D
TaZ |
|
| Top |
|
|
Enrico Placci
Ospite
|
| Inviato: Lun 09 Lug 2007 05:00 Oggetto: udp socket, packet loss |
|
|
On Sun, 08 Jul 2007 19:04:05 +0200
Roberto Bettazzoni <ml@xxxxxx.xyz> wrote:
| Citazione: | Le librerie pitoniche del Mac introducono uno sleep sull'avvio del
thread! Quindi, mentre il thread X "parte" il sistema si fa una
penichella, (e di _almeno_ un microsecondo, la sleep pitonica non ? precisissima), cos?he, al risveglio, quando lancia il thread X+1, il
thread X ?i?toria. Questo giustifica alcune "cose molto strane"
che vedevo sul mac. Non ho parole ... ho solo voglia di spaccare in
due una mela!
|
E` un problema che perseguita l'uomo da Adamo in poi... prendersela con
la mela o con il serpente? :-P
Ciao
Enrico Placci |
|
| Top |
|
|
Guido Bolognesi [ Zen ]
Ospite
|
| Inviato: Lun 09 Lug 2007 07:19 Oggetto: udp socket, packet loss |
|
|
On Sun, Jul 08, 2007 at 07:04:05PM +0200, Roberto Bettazzoni wrote:
| Citazione: | "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/threading.py", line 418, in start
_sleep(0.000001) # 1 usec, to let the thread run (Solaris hack)
|
uh... Solaris?
| Citazione: | Le librerie pitoniche del Mac introducono uno sleep sull'avvio del thread!
|
Le 2.4 ce le hai montate tu, vero?
beepbeep:~ zen$ less /Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/threading.py
/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/threading.py: No such file or directory
Che` il mac viene di default con 2.3... (che ha le stesse righe di commenti
e sleep e porcherie in threading.py).
Tra l'altro, ho pure uno sleep random dentro ProducerThread
_sleep(random() * 0.00001)
uhm...
_________________
guido . zen@xxxxxx.xyz . skype://zenmobile |
|
| Top |
|
|
Fabio Muzzi
Ospite
|
| Inviato: Lun 09 Lug 2007 15:49 Oggetto: udp socket, packet loss |
|
|
On Mon, 2007-07-09 at 06:02 +0200, Enrico Placci wrote:
| Citazione: | E` un problema che perseguita l'uomo da Adamo in poi... prendersela con
la mela o con il serpente? :-P
|
Ma ROFLASTC!!!!
_________________
Fabio "Kurgan" Muzzi |
|
| Top |
|
|
|
|
Non puoi inserire nuovi argomenti
Non puoi rispondere a nessun argomento
Non puoi modificare i tuoi messaggi
Non puoi cancellare i tuoi messaggi
Non puoi votare nei sondaggi
|
|
Forum Subscriptions
FAQ
Cerca
Lista utenti
Gruppi
Registrati
Profilo
Messaggi privati
Log in
