Il modo migliore per inviare dati a un client senza essere bloccati dal firewall

4

Sto facendo questa domanda qui poiché penso che le persone su questo forum probabilmente hanno la migliore conoscenza di firewall e router.

Dire che sto progettando un gioco multi-player e voglio spingere i dati al cliente spontaneamente. Dal momento che è probabilmente più efficiente e mette meno carico sul server rispetto ai client che eseguono costantemente il polling del server per verificare le modifiche.

Da quanto ho capito, la maggior parte dei computer oggi ha firewall e molti computer di casa sono anche dietro un router, quindi se si inviano pacchetti sarà probabilmente bloccato soprattutto perché il router non saprà quale PC instradare il pacchetto in .

Quali sono i modi migliori per inviare dati senza essere bloccati?
In quali situazioni i firewall consentono i pacchetti sui PC con configurazioni predefinite?
e in che modo il router saprà su quale PC indirizzare il pacchetto?

Spero che questa domanda non sia troppo grande, penso che le domande che ho posto siano tutte correlate altrimenti eliminerò l'ultima domanda sul router poiché potrebbe essere meno correlata.

EDIT: dico inviando spontaneamente pacchetti, ma intendo solo dopo che l'utente ha effettuato l'accesso al gioco e ha inviato il suo IP.

EDIT 2: (risposte per commentare)

Il gioco è su Internet.

Quanti traffici - inizialmente avrà forse un centinaio di utenti simultanei, ma dovrebbe essere scalabile per diverse centinaia, ma mi piacerebbe comunque sentire le soluzioni per entrambi i casi perché potrei decidere di avere più server se cambia la risposta.

Latenza - dovrebbe essere il più basso possibile (gioco in tempo reale).

    
posta fiftyeight 21.11.2011 - 21:26
fonte

4 risposte

6

Considerazioni universali

È comune per la maggior parte dei firewall e delle NAT box consentire a un server di rispondere alla macchina che ha inviato un pacchetto dall'interno. Qualsiasi altra cosa è un caso limite o un comportamento folle. Pertanto, se un client di gioco può avviare una connessione con te, possiamo supporre che puoi parlare di nuovo su quel canale. L'obiettivo è quindi mantenere viva la connessione. Con TCP e UDP, i box NAT finiranno il timeout dell'applicazione se non viene inviato nulla.

UDP

Semplice e diretto, la maggior parte dei router NAT consente ai pacchetti UDP di tornare all'host che li ha inviati. Nei giochi in tempo reale, questo è il normale protocollo in modo che il riordino dei frame non venga eseguito sui pacchetti scartati. Il gioco e il suo server sono responsabili della sincronizzazione dei loro stati all'interno del protocollo. Aspettatevi che la connessione venga dimenticata dopo un minuto di silenzio. Le caselle DD-WRT sono predefinite su 2 minuti.

TCP

Il sovraccarico di tenere le connessioni ordinate viene spostato dal gioco al sistema. I pacchetti arrivano all'applicazione in ordine, anche se questo può creare alcuni ritardi indesiderati quando i pacchetti cadono o arrivano al computer fuori servizio. Almeno per RFC, i box NAT dovrebbero mantenere aperta una connessione TCP stabilita per almeno due ore prima di dimenticarli. Realisticamente, contare su non più di 5 minuti. I router DD-WRT, ad esempio, dimenticano il 10.

    
risposta data 21.11.2011 - 23:09
fonte
4

Non si inviano pacchetti fuori dal nulla; devi sapere chi è il cliente e dove si trova. Quindi il modello normale è il seguente: ogni client apre una connessione TCP al server. La connessione sta proprio lì. Quando il server ha qualcosa da dire al client, lo scrive solo sulla connessione pertinente.

Una connessione inattiva non comporta alcun pacchetto. In realtà vuoi per inviare alcuni pacchetti di volta in volta, perché alcuni router / firewall tendono a eliminare le connessioni che sono rimaste inattive per troppo tempo (con "troppo lungo" a volte anche più breve di "cinque minuti" ").

In alcune reti, le connessioni TCP esterne sono negate e tutte le attività di rete devono passare attraverso un proxy sotto il protocollo HTTP (ho visto che in alcune reti aziendali - esattamente la situazione in cui si richiedono regole speciali del firewall per giocare un gioco potrebbe essere in qualche modo disapprovato). La solita soluzione alternativa è quella di utilizzare HTTPS (ad esempio SSL), poiché in tal caso il proxy funzionerà come un generico TCP forwarder bidirezionale (con il comando CONNECT proxy). Se anche questo è bloccato, dovrai ricorrere a trucchi come l'invio di una richiesta HTTP fittizia e far inviare al server una risposta "illimitata" (una risposta senza un'intestazione "Content-Length" esplicita) da piccoli pezzi. Vedi questo post del blog per una discussione.

    
risposta data 21.11.2011 - 21:50
fonte
1

RISPOSTA RAPIDA:

Il problema generale per i router domestici, o firewall, è che consentono connessioni esterne e non consentono di rientrare.

Ogni marchio / modello ha generalmente le stesse funzionalità per consentire un bypass o una mappatura delle porte verso l'interno. Ma il metodo esatto (GUI, impostazioni) può essere molto diverso (e quindi complesso).

Sarebbe sicuramente più sicuro avere i client connettersi (al server). Ma per mandare ancora principalmente (da server ), potresti avere il client prima di stabilire una connessione esterna e poi ascoltare i pacchetti su quel percorso.

    
risposta data 21.11.2011 - 22:01
fonte
1

Una risposta breve è che hai bisogno che il client si comporti come un cliente, cioè inizia la connessione per i dati "inviati".

Come dici tu, le connessioni UDP e TCP avviate all'estremità "server" non attraverseranno la maggior parte dei firewall e non attraverseranno la maggior parte dei router NAT.

Effettivamente, anche con il socket avviato dall'utente, otterrai la migliore copertura usando la porta 80 - quindi dovresti almeno considerare comet

(Tuttavia IME, la maggior parte dei MORPG si basa sull'utente che autorizza esplicitamente le connessioni in entrata.)

Questo è uno dei problemi che websockets sono destinati a risolvere.

In entrambe le architetture si verificheranno seri problemi di scalabilità utilizzando un modello di server convenzionale con un thread / processo per connessione. (vai a leggere su node.js).

Non sorprendentemente node.js ha un ottimo supporto per websocket.

    
risposta data 22.11.2011 - 18:08
fonte

Leggi altre domande sui tag