Assistenza remota simil Team Viewer

[DragoRosso]

Aggiornamento.

Faccio seguito ad alcune prove effettuate (che purtroppo confermano quanto ipotizzato).

L'uso di UDP tramite firewall, router o altri filtri di rete non consente di eseguire una connessione "identificata": cosa significa?

Significa che non c'è modo di identificare e ridirigere correttamente un pacchetto UDP che proviene dall'esterno di una LAN e arriva all'interno della stessa in assenza di una apertura esplicita delle porte.

Cosa accade:

1) un client (A) invia un pacchetto UDP (XP) a un server su Internet. Nessuna porta aperta esplicitamente sui dispositivi di rete (firewall, router, etc ...);

2) Il pacchetto UDP (XP) arriva al server su Internet.

3) Nel frattempo i dispositivi di rete tra client (A) e server su Internet hanno annotato che del traffico tra il client (A) e il server Internet è stato effettuato, e che presumibilmente ci potrebbe essere una risposta UDP all'inverso. Quindi aprono una finestra temporale variabile (diciamo tra i 30 e i 60 secondi) in cui consentiranno che i pacchetti UDP dal server Internet arrivino all'interno della LAN sino al client (A) ATTRAVERSO LE STESSE PORTE USATE PER LA PRIMA TRASMISSIONE.

4) Il server su Internet invia un pacchetto UDP (YP) verso il client (A) .... client che viene identificato con l'indirizzo IP pubblico ovviamente !!!!!! non certamente con l'indirizzo IP della LAN.

Fino a qui tutto bene.

Ora avviene il fattaccio:

un secondo client (B) da un'altra postazione invia un pacchetto UDP (ZP) sempre al server su Internet usando sempre le stesse porte del client (A) .... quando il server su Internet risponde, il pacchetto UDP (WP) arriva al client (A) invece che al client (B).

Tutto ciò è assolutamente normale ... per l'UDP.

I sistemi di rete "registrano" il transito dei pacchetti e identificano eventuali "risposte" solo dalla porta usata (sarebbe tecnicamente come effettuare un NAT temporaneo, questo per i pacchetti UDP). Se tutti i client usano le stesse porte, allora i pacchetti di risposta arriveranno al primo che ha avviato la comunicazione.

Ovviamente su TCP tutto è diverso, non ci sono problematiche nell'identificazione dei client / server a cui ridirigere i pacchetti.

Ciò detto, che come accennavo è come ci si aspettava, porta alla conclusione che il sistema desktop remoto dovrà basarsi su TCP e non su UDP. E se da un certo punto di vista ciò migliora sicurezza e "meccanismi" di gestione, da un punto di vista meramente prestazionale complica le cose in particolar modo dove le connessioni sono particolarmente "instabili" come nelle zone malservite dagli operatori o quando ci sono connessioni wireless.

Posterò a breve il sorgente per fare i test (sempre uno scheletro, senza gestione di errori o quant'altro).

Ciao

[DragoRosso]

Progetto Client in UDP per test KRD.

Ciao

[DragoRosso]

Aggiornamento:

a seguito delle prove effettuate, ho implementato temporaneamente visto il tempo che avevo a disposizione una connessione TCPS (cioè una connessione TCP tramite TLS1.2). La cifratura avviene tramite chiper "ECDHE-RSA-AES128-GCM-SHA256" in prima battuta, seguono altri se per qualsiasi motivo questa non fosse usufruibile.

Implemento il serverino con queste implementazioni e aggiorno anche il client.

N.B.: Il client avrà un normale socket TCP, senza DLL o altro  .... ehm ovviamente servono le cryprolib per adesso sino a quando non svilupperemo il modulo in pascal.

[xinyiman]

Ok, quando hai qualcosa da farci provare su cui instaurare ulteriori prove faccelo sapere.

Come dicevamo ieri, sarebbe opportuno stilare il protocollo per l'interscambio dei dati

[DragoRosso]

Cosa dite: ci limitiamo ad un miliardo di sistemi connessi, o ci proiettiamo subito un pò più in grande ? 

Mi piace la parte di progettazione, dove si può far galoppare la fantasia.

Un pò di sano umorismo ogni tanto fà bene.

Un "OT" giustificato.

Ciao

[xinyiman]

Spariamo pure in alto, possiamo sempre cambiare idea se troviamo grossi ostacoli

[DragoRosso]

Ok, quando hai qualcosa da farci provare su cui instaurare ulteriori prove faccelo sapere.

Come dicevamo ieri, sarebbe opportuno stilare il protocollo per l'interscambio dei dati

Per adesso mi stò concentrando sulla costruzione e "derivazione" del componente base (Context) che identifica la connessione con un client, compresa la gestione multithreading.

L'ho derivato, e messo già in uso totalmente e funziona. Quindi ora possiamo costruire sopra questo ciò che ci aggrada.

Non è un processo corretto lo sò (prima progettare poi scrivere codice), ma ci sono alcuni aspetti che nella progettazione implicano conoscenza e in questo caso la conoscenza si "ipotizza" e si acquisisce con alcune prove reali.

Stò costruendo la funzionalità di tunneling trasparente tra due client "registrati" nel server, poi mi dedico al protocollo insieme a voi.

Fatto il tunneling si potranno già subito testare alcune funzionalità che servono per la gestione grafica. Qualche giorno di pazienza e un primo vagito emergerà dalla nebbia.

Ciao

[nomorelogic]

mi sono documentato un po' in giro per il confronto tra 2 bitmap
metto quì un link che mi sembra interessante, probabilmente ci faciliterà un po' il lavoro

https://forum.lazarus.freepascal.org/index.php/topic,26462.0.html

[DragoRosso]

Progressi sul fronte protocollo.

Ciao

[DragoRosso]

mi sono documentato un po' in giro per il confronto tra 2 bitmap
metto quì un link che mi sembra interessante, probabilmente ci faciliterà un po' il lavoro

https://forum.lazarus.freepascal.org/index.php/topic,26462.0.html

Si, interessante.
Io tenterei però di leggere una intera linea raster e fare un confronto in memoria (memcmp ... esiste ancora ?) penso che sia la più veloce e approcciabile.
Mi pare, vado a memoria che ci impiegavo una quindicina di millisecondi a scansionare a triplette (24 bit RGB) una full hd (1920 x 1080)
Mantenendo in memoria sui due lati client le rispettive vecchie "bitmap" si sovrascrivono le righe variate.

Poi ogni tot si invia un frame intero.

L'intestazione dello streaming potrebbe avere:
0: frame intero;
n: riga inviata (con  1 <= n <= 1080 ad esempio sempre per uno schermo full hd).

Ciao

PS: poi se vogliamo spendere 2000,00 € di licenza runtime a client vi posso fare la scansione e il confronto in qualche decina di microsecondi ... ma non mi sembra il caso ... 

[DragoRosso]

Il sistema di comunicazione è in "piedi", il server si chiama "korgrd.dyn-o-saur.com".

E' stato implementato il canale comandi con i client con handshake delle prime info:

1) Richiesta nuovo ID;

2) Richiesta lista connessioni registrate;

3) Richiesta stato client;

Il client adesso parte, si connette al server con un ID di default (come fosse il primo "contatto") e richiede un nuovo ID.
Per ora non viene gestito ne il DB sul server per mantenere in maniera permanente gli ID, ne alcunchè sui client.

Ora la mia idea sarebbe, alla pari di altri protocolli come l'RTP (RTSP), e come anche suggerito da @xinyman di aprire un canale aggiuntivo temporaneo alla richiesta di connessione tra due client creando un tunneling sul server. Su questo canale viaggeranno gli streaming di tutti i dati tra i due client.

Tutto ciò sarebbe bello ma .... c'è sempre un ma.

All'interno delle reti gestite (tipo aziendali, eccetto quelle più "grosse" con servizi proxy autenticati), l'accesso "all'esterno" è normalmente garantito a chi usa come destinazione porte note come la 80, la 443 o le porte per i vari protocolli mail (IMAP, POP, SMTP) e vengono bloccate le altre. Quindi se manteniamo questa logica, e la connessione principale avverrà sulla porta 80 del server internet, la connessione secondaria potrebbe avvenire sulla 443 (che su un server proprietario potrebbe essere libera, ma normalmente non lo è su un server "pubblico").

Ad esempio sul mio server (che ho qui in ufficio), la 443 è comunque impegnata per altri servizi. Si possono usare ovviamente altre porte ma come accennavo l'eventuale difficoltà potrebbe essere che in certe realtà il client potrebbe non riuscire a connettersi con il flusso secondario.

L'alternativa è usare una unica porta (la 80 ad esempio) e gestirla nel server (poi quando saremo scafati si potrà implementare il check delle porte remote e se raggiungibili passare in dinamico alla configurazione con più "pool di porte).

Di fatto non cambia nulla, solo che invece di avere diversi gruppi di "listener" abbinati alle singole porte ne avremo solo uno.

Sono da tenere in seria considerazione le prestazioni.

Un sistema di teleassistenza comune occupa le seguenti bande (schermo remoto FULL HD, impostazioni su MIGLIORE VELOCITA' DI REAZIONE / QUALITA' BASSA):

1) Solo movimento mouse -> tra i 40Kbit e gli 80Kbit in uscita dal client remoto e punte di 120Kbit in ingresso;

2) Movimento del mouse con una finestra agganciata dalle dimensioni di mezzo schermo -> dai 4Mbit ai 26Mbit in uscita dal client remoto con punte di 240 Kbit in ingresso.

Ovviamente più client in tunelling e la richiesta di banda aumenterà a dismisura, con il risultato che necessiterà ben più di una connessione al server di 1 Gbit come la mia e un PC come hardware ...

Però, per un uso "personale" ossia un uso dove la teleassistenza la fanno da uno a tre persone in contemporanea al massimo, il sistema che stiamo pensando dovrebbe essere sufficientemente prestante.

E poi sarà fatto in Pascal 

Ciao

[DragoRosso]

Per andare sul concreto in questa fase aprirei un canale (connessione tcp/ip) sulla stessa porta del "canale comandi" per ogni servizio:

1) streaming video;
2) mouse, tastiera e simili;
3) audio (sarà sviluppato come ultimissima cosa).
4) canale ausiliario ulteriore per trasferimenti file (anche questo sarà una delle ultime implementazioni).

E da verificare la funzionalità di sincronismo tra video e mouse / tastiera.

Quindi oltre alle connessioni dei singoli client, ogni client in teleassistenza avrà 4 connessioni aggiuntive.

Se ciò va bene, implemento la cosa affinchè le prime due voci siano usabili da voi che farete la parte video / mouse / tastiera).

Poi in una futuribile videochiamata defineremo le linee guida del protocollo.

Ciao

[xinyiman]

Direi che va benone

[xinyiman]

Intanto io sto cercando di fare gli screenshot di un sistema multimonitor. Qui le prime considerazioni e richieste d'aiuto.

https://forum.lazarus.freepascal.org/index.php/topic,63151.0.html

[DragoRosso]

Intanto io sto cercando di fare gli screenshot di un sistema multimonitor. Qui le prime considerazioni e richieste d'aiuto.

https://forum.lazarus.freepascal.org/index.php/topic,63151.0.html

Ti ho risposto io sul forum internazionale. Devi ricalcolarti le quote (nel mio caso le X) dei vertici del secondo monitor a causa del differente o ingrandimento o differente DPI dei due monitor.

Ciao

P.S.: nel mio caso primo monitor 2450 a 125% -> Windows ti dice che il secondo monitor si trova a 3200, invece non è così. Non sò se no i manifest DPI AWARE risolvi la cosa senza fare tanti calcoli.