Torna indietro   Hardware Upgrade Forum > Software > Programmazione

Attenti a Poco F7: può essere il best buy del 2025. Recensione
Attenti a Poco F7: può essere il best buy del 2025. Recensione
Poco F7 5G, smartphone che punta molto sulle prestazioni grazie al processore Snapdragon 8s Gen 4 e a un display AMOLED da ben 6,83 pollici. La casa cinese mantiene la tradizione della serie F offrendo specifiche tecniche di alto livello a un prezzo competitivo, con una batteria generosissima da 6500 mAh e ricarica rapida a 90W che possono fare la differenza per gli utenti più esigenti.
Recensione Samsung Galaxy Z Fold7: un grande salto generazionale
Recensione Samsung Galaxy Z Fold7: un grande salto generazionale
Abbiamo provato per molti giorni il nuovo Z Fold7 di Samsung, un prodotto davvero interessante e costruito nei minimi dettagli. Rispetto al predecessore, cambiano parecchie cose, facendo un salto generazionale importante. Sarà lui il pieghevole di riferimento? Ecco la nostra recensione completa.
The Edge of Fate è Destiny 2.5. E questo è un problema
The Edge of Fate è Destiny 2.5. E questo è un problema
Bungie riesce a costruire una delle campagne più coinvolgenti della serie e introduce cambiamenti profondi al sistema di gioco, tra nuove stat e tier dell’equipaggiamento. Ma con risorse limitate e scelte discutibili, il vero salto evolutivo resta solo un’occasione mancata
Tutti gli articoli Tutte le news

Vai al Forum
Rispondi
 
Strumenti
Old 28-06-2007, 15:25   #1
nuovoUtente86
Senior Member
 
Iscritto dal: Mar 2007
Messaggi: 7863
[java] Datagram e concorrenza.

Mentre conosco bene il Tcp e riesco ad implementare benissimo la concorrenza,ho notato che per quanto riguarda l' UDP lat server non si fa mai utilizzo dei thread come se la concorrenza fosse gia data di default dal protocollo.Mi chiedo come si fa a gestire l' arrivo multiplo di pacchetti sul server?
Il metodo recive() è bloccante?

Grazie.
nuovoUtente86 è offline   Rispondi citando il messaggio o parte di esso
Old 28-06-2007, 15:56   #2
andbin
Senior Member
 
L'Avatar di andbin
 
Iscritto dal: Nov 2005
Città: TO
Messaggi: 5206
Quote:
Originariamente inviato da nuovoUtente86 Guarda i messaggi
Mentre conosco bene il Tcp e riesco ad implementare benissimo la concorrenza,ho notato che per quanto riguarda l' UDP lat server non si fa mai utilizzo dei thread come se la concorrenza fosse gia data di default dal protocollo.Mi chiedo come si fa a gestire l' arrivo multiplo di pacchetti sul server?
Il metodo recive() è bloccante?
Sì: "This method blocks until a datagram is received.".

Comunque per la concorrenza non credo che ci siano problemi a farla: appena ricevi un pacchetto, crei un nuovo thread passandogli il pacchetto e ritorni ad aspettare un nuovo pacchetto.
Nel thread farai quello che devi fare ed invierai la risposta, se necessaria (nota che nel pacchetto hai le informazioni sul mittente!).
__________________
Andrea, SCJP 5 (91%) - SCWCD 5 (94%)
andbin è offline   Rispondi citando il messaggio o parte di esso
Old 28-06-2007, 16:11   #3
nuovoUtente86
Senior Member
 
Iscritto dal: Mar 2007
Messaggi: 7863
nel codice di molti tutorial c' è qualcosa del genere

while(nn si verifica un' eccezione){
ricevi un pacchetto
rielabora la richiesta
invia il pacchetto}
//questo mi sembra non multithread giusto?
mentre il metodo elabora il pacchetto ,gli altri pacchetti in arrivo vengono accodati o si perdono?

Secondo te la variabile DatagramSocket che dovrebbe essere condivisa fra i tre e il metodo send() in particolare andrebbero protetti con un monitor oppure no,ma in tal caso cosa succede se si verifica :

thread1 fa socket.send(pacchetto1)
thread2fa socket.send(pacchetto2)
?

Nel tcp tale problema nn si pone in quanto il ServerSocket un avolta ricevuto il socket non deve occuparsi piu di nulla.
In realtà si potrebbe anche evitare di condividere il DatagramSocket istanziandone uno uno in ogni thread,che ne pensi?
Ma come mai da nessuna parte ne ho trovato una implementazione multithread?

Ultima modifica di nuovoUtente86 : 28-06-2007 alle 16:25.
nuovoUtente86 è offline   Rispondi citando il messaggio o parte di esso
Old 28-06-2007, 17:07   #4
andbin
Senior Member
 
L'Avatar di andbin
 
Iscritto dal: Nov 2005
Città: TO
Messaggi: 5206
Quote:
Originariamente inviato da nuovoUtente86 Guarda i messaggi
while(nn si verifica un' eccezione){
ricevi un pacchetto
rielabora la richiesta
invia il pacchetto}
//questo mi sembra non multithread giusto?
Esatto. Si chiama server "sequenziale" (o "iterativo").

Quote:
Originariamente inviato da nuovoUtente86 Guarda i messaggi
mentre il metodo elabora il pacchetto ,gli altri pacchetti in arrivo vengono accodati o si perdono?
Si accodano (finché possibile). Esiste un buffer. Quale sia la capacità di questo buffer, non lo so. Sicuramente poi è diversa da un sistema operativo all'altro.

Quote:
Originariamente inviato da nuovoUtente86 Guarda i messaggi
Secondo te la variabile DatagramSocket che dovrebbe essere condivisa fra i tre e il metodo send() in particolare andrebbero protetti con un monitor oppure no,ma in tal caso cosa succede se si verifica :

thread1 fa socket.send(pacchetto1)
thread2fa socket.send(pacchetto2)
?
Su questo non ne ho idea, dovrei documentarmi.

Quote:
Originariamente inviato da nuovoUtente86 Guarda i messaggi
Nel tcp tale problema nn si pone in quanto il ServerSocket un avolta ricevuto il socket non deve occuparsi piu di nulla.
In realtà si potrebbe anche evitare di condividere il DatagramSocket istanziandone uno uno in ogni thread,che ne pensi?
Pure qui dovrei documentarmi. Suppongo che sia fattibile.

Quote:
Originariamente inviato da nuovoUtente86 Guarda i messaggi
Ma come mai da nessuna parte ne ho trovato una implementazione multithread?
Dipende ovviamente da cosa si deve fare di preciso, ma per cose "normali" immagino che sia sufficiente un server sequenziale.
__________________
Andrea, SCJP 5 (91%) - SCWCD 5 (94%)
andbin è offline   Rispondi citando il messaggio o parte di esso
Old 28-06-2007, 18:18   #5
nuovoUtente86
Senior Member
 
Iscritto dal: Mar 2007
Messaggi: 7863
un domanda riguardo il TCP:quando il server nn è sul metodo accept(),le richieste di connessione decadono o si incodano?
nuovoUtente86 è offline   Rispondi citando il messaggio o parte di esso
Old 28-06-2007, 23:27   #6
nuovoUtente86
Senior Member
 
Iscritto dal: Mar 2007
Messaggi: 7863
Quote:
Originariamente inviato da andbin Guarda i messaggi
Si accodano (finché possibile). Esiste un buffer. Quale sia la capacità di questo buffer, non lo so. Sicuramente poi è diversa da un sistema operativo all'altro.

.
Ma dell' occodamneto dei pacchetti se ne occupa il SO o Java o entrambi?

Ciòè arrivano 10 pacchetti sulla porta 10000 è il sistema operativi ad accodarli e poi passarli singolarmente all' applicazione(il programma java in questo caso) oppure il sistema li passa a java che in modo trasparente all' utente(programmatore) li accoda?
nuovoUtente86 è offline   Rispondi citando il messaggio o parte di esso
Old 29-06-2007, 08:52   #7
andbin
Senior Member
 
L'Avatar di andbin
 
Iscritto dal: Nov 2005
Città: TO
Messaggi: 5206
Quote:
Originariamente inviato da nuovoUtente86 Guarda i messaggi
un domanda riguardo il TCP:quando il server nn è sul metodo accept(),le richieste di connessione decadono o si incodano?

Ma dell' occodamneto dei pacchetti se ne occupa il SO o Java o entrambi?

Ciòè arrivano 10 pacchetti sulla porta 10000 è il sistema operativi ad accodarli e poi passarli singolarmente all' applicazione(il programma java in questo caso) oppure il sistema li passa a java che in modo trasparente all' utente(programmatore) li accoda?
Innanzitutto tieni presente che il TCP è un protocollo con "connessione". Vuol dire che prima che client e server si possano scambiare dei dati, è necessario aprire una connessione, accettata da entrambi. Esiste un protocollo ben preciso, che utilizza un handshake composto da 3 passi.
Pertanto fino a quando la connessione non è accettata dal server (con la accept() ), è solo half-open. Ed esiste un coda che mantiene le connessioni in attesa di accettazione da parte del server. Se la coda è piena, le successive richieste di connessione vengono semplicemente rifiutate.
La dimensione di tale coda (backlog) è parametrabile su ogni singolo server socket, basta leggere la documentazione della funzione listen() (mi sto riferendo alla funzione "nativa" dei socket utilizzabile in "C").
A livello di Java, quando costruisci un ServerSocket, puoi specificare la dimensione del backlog tramite il suo costruttore.

Vedi i link, please:

listen() nativa dei socket: http://msdn2.microsoft.com/en-us/library/ms739168.aspx
ServerSocket (Java): http://java.sun.com/javase/6/docs/ap...verSocket.html
TCP: http://en.wikipedia.org/wiki/Transmi...ntrol_Protocol
__________________
Andrea, SCJP 5 (91%) - SCWCD 5 (94%)
andbin è offline   Rispondi citando il messaggio o parte di esso
 Rispondi


Attenti a Poco F7: può essere il best buy del 2025. Recensione Attenti a Poco F7: può essere il best buy...
Recensione Samsung Galaxy Z Fold7: un grande salto generazionale Recensione Samsung Galaxy Z Fold7: un grande sal...
The Edge of Fate è Destiny 2.5. E questo è un problema The Edge of Fate è Destiny 2.5. E questo ...
Ryzen Threadripper 9980X e 9970X alla prova: AMD Zen 5 al massimo livello Ryzen Threadripper 9980X e 9970X alla prova: AMD...
Acer TravelMate P4 14: tanta sostanza per l'utente aziendale Acer TravelMate P4 14: tanta sostanza per l'uten...
Half-Life 3? No, Gabe Newell produrr&agr...
Apple al lavoro su un sensore che "...
TSMC vittima di spionaggio industriale s...
Cooler Master MasterFrame 500: un flusso...
Apple accelera sull'IA interna: c'&egrav...
I robotaxi arrivano in Europa: Lyft e Ba...
Ancora voci sul mega tablet pieghevole d...
Un computer quantistico con 10.000 qubit...
AVM cambia nome e faccia: ora si chiama ...
SatNet ha lanciato altri satelliti per l...
Flop autonomia per la Fiat Grande Panda ...
2 TV LG da favola in super sconto: OLED ...
Potrebbe essere fallito il test del prot...
iPhone 17 si prepara al debutto: trapela...
L'uomo che ha perso 8000 Bitcoin in una ...
Chromium
GPU-Z
OCCT
LibreOffice Portable
Opera One Portable
Opera One 106
CCleaner Portable
CCleaner Standard
Cpu-Z
Driver NVIDIA GeForce 546.65 WHQL
SmartFTP
Trillian
Google Chrome Portable
Google Chrome 120
VirtualBox
Tutti gli articoli Tutte le news Tutti i download

Strumenti

Regole
Non Puoi aprire nuove discussioni
Non Puoi rispondere ai messaggi
Non Puoi allegare file
Non Puoi modificare i tuoi messaggi

Il codice vB è On
Le Faccine sono On
Il codice [IMG] è On
Il codice HTML è Off
Vai al Forum


Tutti gli orari sono GMT +1. Ora sono le: 16:23.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
Served by www3v