Newsgroup: it.comp.reti.locali
Titolo: UDP e LAN

Ho realiizato un'applicazione C/S che utilizza UDP, un client che richiede
un servizio viene iscritto sul server e resta in attesa di una sequenza
(anche infinita) di pacchetti UDP.
Sorge un problema per client apparteneti a LAN, poichè l'IP di ogni client è
quello del router della LAN, quindi il server invia a questo indirizzo il
pacchetto destinato al client, ma quest'ultimo non lo riceverà mai...
Esiste una soluzione o devo abbandonare l'idea dell'UDP?
Grazie.


preg
--------------------------------------------------
PLASMA - GnomeICU (ICQ) 2116658
Sbavatore ufficiale #1 di Madoka Ayukawa
Fan #1 di Pascal-X
Membro dello Swiss IAC District
GNAGNA!

Mentre mi chiedevo perche Daitarn 3 non lo usava subito quel cazzo di
Attakko ad Energia Solare, 
t7...@hotmail.ch
 (PLASMA) si mette a
scrivere:
OPSSS sorry ho letto male! non e questa la solutione!
di solito quando una makkina in una LAN (senza IP pubblico) butta
fuori un pakketto verso internet.. il router gli mappa una porta
destinata al pakketto di ritorno.. (infatti nel header tcp come source
port ci infila quella) quando tornano i pakketti vengono ricevuti su
quella porta e il router li forwarda al macchina interna a cui sono
destinati.. dunque.. divrebbe essere tutto automatico per te.. 
il fatto che non va.. mi fa pensare che il tuo progrmma (server)
quando manda i pakketti di ritorno non ci infila la destination port
giusta.. possibile? 
spero di averti dato qualche buona dritta! :))
come al solito in caso di vakkate insultatemi pure qui! :)))


 Esiste una soluzione o devo abbandonare l'idea dell'UDP?
Udp potrebbe andare bene, chiarisci meglio la situazione.
-- 
Vincenzo 
A volte a Lourdes i film muti si mettono a parlare.

 > Sorge un problema per client apparteneti a LAN, poichè l'IP di ogni
client è


 risulta avere IP del router.
Quindi il router dovrebbe svolgere la funzione di nat dinamico. In questa
configurazione devi strutturare l'applicazione in modo che sia sempre il
client ad aprire la connessione verso il server. Inoltre non devi 
includere gli indirizzi ip dei client all'interno dei dati scambiati
tra client e server. Per ultimo una volta che il client si registra
sul server, non devi far passare troppo tempo (circa due o tre minuti)
per inviare i dati al client stesso, altrimenti il router pensera` che 
la comunicazione tra client e server e` finita e` rimuovera` il client 
dalla nat table.


 risulta avere IP del router.
Impossibile, questa LAN non potrebbe funzionare! UPD o TCP sono uguali e la
coppia IP/porta src/dest identificano univocamente un client in rete!
Nel tuo caso il router fa NAT, ma non capisco cosa ti freghi... tu vedi si
l'IP del router (con porte diverse per altro), ma il router sa a chi
destinare il pacchetto! Non mi e' chiaro xche' la tua applicazione sia
diversa da qualunque altro applicativo e.g. una qualunque connessione web

 wrote in message
9if74j$i6jtc$1...@ID-65620.news.dfncis.de...


 Tutto funziona nella mia LAN ma non al di fuori dei essa
vedo che nessuno ha aggiunto nulla, ecco i miei 10 pence.
Deve funzionare xche' e' indifferente LAN o WAN sotto questo aspetto, pero'
vedo:
- il client potrebbe essere dietro firewall che filtra la connesione
- il client NATtato da un router ha cambiato la connessione tra lui ed il
router stesso (ovvero e' su un'altra porta)... guarda che il router non
tiene su la connessione in eterno...
pronti via non mi viene altro, fammi sapere

 destinata al pakketto di ritorno..
Questo č facile per TCP perchč č possibile associare ogni pacchetto alla
connessione attiva a cui appartiene, quasi impossibile per UDP che non usa
connessione.
Normalmente i router "piů bravi" usano dei sistemi studiati ad-hoc per i
protocolli UDP piů comuni (credo solo DNS). Per il resto ciccia!
Mau

 ciccia!
Basta evitare di usare gli indirizzi ip dei client dietro il nat nel 
payload e tutto funzionera' senza problemi.
Ciao,
Vincenzo.

 payload e tutto funzionera' senza problemi.
se ho capito bene ui non usa l'IP della LAN (xche' NON lo vede), ma risponde
dopo troppo tempo e la connessione non esiste piu'. Se cosi' fosse TCP non
risolverebbe.
Va bene qualunque protocollo, ma deve tenere la connessione "su" sul
router... qualche pacchetto "inutile" ogni chesso' 20 secondi?

 risponde
Mi riferivo all'applicazione client. Se il client che si registra sul
server gli passa il suo ip (quello del client) in maniera esplicita
(cioe` in qualche struttura dati) allora ci potrebbero essere dei
problemi. Se invece il server si basa solo sull'ip che legge dal
socket, comunichera` sempre con il router (come ip) e questi
inoltrera` la risposta al client interno.


 problemi.
Ah scusa, certamente! Non ci avevo pensato... ma sarebbe un errore di
progetto!!!!!!
[Tanto continuiamo a parlare e ci siamo persi colui che fece la domanda...]

 esterno. Funziona tranquillamente con udp.
Si, è vero fanno così, ma questa non è una soluzione, è un palliativo.
UDP, non essendo connesso, è un po' scorbutico e si presta a implementazioni
fantasiose.
Infatti router e firewall vantano appositi "fixup" studiati per i protocolli
UDP specifici.
Normalmente funziona, sono anche convinto che esista una modalità standard,
ma per esperienza ho visto che non sempre funziona e non mi ci affiderei
troppo.
Esempio:
Rete casalinga, due PC su una rete mascherata da un router che fa NAT verso
internet.
Il primo si mette a gicare ad UnrealTurnament(porta UDP:7777) su un server
su internet, il router reinoltra la richiesta a suo nome. Il server risponde
alla porta 7777 dell'indirizzo del router e il router, se la porta
corrisponde e la finestra è ancora aperta (sono diventato falegname!), lo
reinvia al primo PC.
Il secondo PC inizia a giocare a Unreal sullo stesso server, il router lo
reinoltrerà e il server risponderà sempre alla porta 7777 dell'indirizzo del
router. A questo punto il router a chi invierà il pacchetto UDP?
Se il server rispondesse sulla porta da cui sono arrivate le richieste
sarebbe tutto OK ma se il server risponde su una porta fissa? Allora è un
casino?
Mau

 lo reinoltrerà e il server risponderà sempre alla porta 7777 
Il nat alloca una porta diversa (sorgente) per ogni client. E` per 
questo che funziona ;) altrimenti la cosa sarebbe impossibile anche
per tcp.
C1-->Udp 1234:7777 --> Router 6000:7777 ---> Server
C2-->Udp 1234:7777 --> Router 6001:7777 ---> Server
.....
Dove 1234 e` la porta sorgente del client.
Cosi` il server rispondera` allo stesso ip (quello del router) ma su
porte diverse. Il nat funziona benissimo con udp, basta solo non avere
nei dati scambiati l'ip del client (che e` privato quindi irragiungibile
direttamente dal server). Se, come l'originatore del thread, devi 
scriverti un'applicazione che viaggia su udp, basta tener conto di
questa limitazione.


C2-->Udp 1234:7777 --> Router 6001:7777 ---> Server
eh.. e io che ho detto? :))))) 
