Assistenza remota simil Team Viewer

[DragoRosso]

Scriverlo da zero và bene. Anche la parte di gestione delle immagini secondo me andrebbe ripensata ... sul Jpeg non sono d'accordissimo visto che bisogna "streamarlo" e non salvarlo. Indy ha già integrata la compressione con lo stream e potrebbe bastare quello (magari opzionabile con il Jpeg).

Il concetto è che il carico di "extra lavoro" portato da KRD sul lato in assistenza dovrebbe essere il più basso possibile per non influire con il funzionamento normale del sistema.
Poi ovvio che si dovranno predisporre opzioni tipo:
1) Meglio qualità;
2) Bilanciamento prestazioni / qualità;
3) Meglio prestazioni;
4) Meglio ottimizzare il trasporto di rete.

Ciao

P.S.: KRD è l'acronimo del progetto.

[xinyiman]

Scriverlo da zero và bene. Anche la parte di gestione delle immagini secondo me andrebbe ripensata ... sul Jpeg non sono d'accordissimo visto che bisogna "streamarlo" e non salvarlo. Indy ha già integrata la compressione con lo stream e potrebbe bastare quello (magari opzionabile con il Jpeg).

Il concetto è che il carico di "extra lavoro" portato da KRD sul lato in assistenza dovrebbe essere il più basso possibile per non influire con il funzionamento normale del sistema.
Poi ovvio che si dovranno predisporre opzioni tipo:
1) Meglio qualità;
2) Bilanciamento prestazioni / qualità;
3) Meglio prestazioni;
4) Meglio ottimizzare il trasporto di rete.

Ciao

P.S.: KRD è l'acronimo del progetto.

Assolutamente concordo con tutto. Anche KRD può essere rivisto come nome, io lo avevo chiamato così perchè Korg è un personaggio secondario (ma importante) del fumetto Martin Mystere (uno dei miei preferiti).

[xinyiman]

Solo una cosa, il fatto che io passo da una jpeg è dovuta al fatto che riduco la qualità dell'l'immagine e la comprimo prima di trasmetterla. Questo per permttere una trasmissione più rapida. Però se hai idea alternative per migliorare le performance di trasmissione ben venga.

[DragoRosso]

Ulteriore cosa:

come concetto base direi di mantenere i dati del lato in assistenza così come sono, senza conversione nè altro (ovviamente in generale parlo) e di convertire quanto serve sul lato da cui parte l'assistenza.

Quindi il desktop ad esempio viene solo compresso e non convertito e poi inviato così com'è. Ci penserà poi chi lo riceve ad effettuare le necessarie conversioni.
Esempio (solo dimostrativo, pratico):

1) presa immagine desktop pc windows, formato bitmap;
1a) eventuale riduzione di formato per ottimizzare le prestazioni per esempio da 4k a FD.
2) compressione formato bitmap tramite stream;
3) ricezione lato MAC e conversione in PCX per la visualizzazione.

Ciao

[xinyiman]

Ulteriore cosa:

come concetto base direi di mantenere i dati del lato in assistenza così come sono, senza conversione nè altro (ovviamente in generale parlo) e di convertire quanto serve sul lato da cui parte l'assistenza.

Quindi il desktop ad esempio viene solo compresso e non convertito e poi inviato così com'è. Ci penserà poi chi lo riceve ad effettuare le necessarie conversioni.
Esempio (solo dimostrativo, pratico):

1) presa immagine desktop pc windows, formato bitmap;
1a) eventuale riduzione di formato per ottimizzare le prestazioni per esempio da 4k a FD.
2) compressione formato bitmap tramite stream;
3) ricezione lato MAC e conversione in PCX per la visualizzazione.

Ciao

Non ho ben capito ma mi fido. Non capisco però perchè devi prenderti il bitmap e poi comprimerlo. Fallo passando da una jpg. Non è più facile?

[DragoRosso]

Solo una cosa, il fatto che io passo da una jpeg è dovuta al fatto che riduco la qualità dell'l'immagine e la comprimo prima di trasmetterla. Questo per permttere una trasmissione più rapida. Però se hai idea alternative per migliorare le performance di trasmissione ben venga.

La compressione JPEG và bene, ma occupa comunque risorse. Magari una semplice compressione gzip impiega meno risorse e ottiene un risultato simile.
Dopo una compressione JPEG non ha comunque senso un stream compresso, non può esserci una ulteriore compressione.

Si tratta di verificare qual'è il bilanciamento migliore.

Stò anche soppesando, per usi di un certo tipo, anche i compressori video. Li uso per fare lo streaming su disco delle mie elaborazioni di linea in real time.
Però di quelli non ci sono sorgenti in pascal (e non ci potranno essere), quindi solo librerie (dll, so, dylib).
Un vecchissimo compressore (  ) anni 90 di Microsoft streamma a 167 kbit al secondo un desktop QHD come il mio (5 fotogrammi al secondo). In questo caso è integrato in Windows, niente dll esterne. Ovviamente usando un X264 o x265 le prestazioni / qualità aumentano. Io uso normalmente un x264 (minor uso di CPU per la qualità che mi serve).

Ciao

PS: x264 era la vecchia tecnica di trasmissione del digitale terrestre, x265 è quella nuova.

[DragoRosso]

Non ho ben capito ma mi fido. Non capisco però perchè devi prenderti il bitmap e poi comprimerlo. Fallo passando da una jpg. Non è più facile?

Il desktop generalmente si "cattura" in "bitmap" (lasciando perdere GDI, GTK o altro), per averlo in jpeg occorre "trasformarlo". Questo fatto secondo me costa più in termini di risorse che non inviarlo ad uno stream con compressione.
Però è una mia supposizione, magari mi sbaglio.

Quando saremo in fase esecutiva si farà qualche prova e si vedrà. Comunque potranno rimanere entrambe le opzioni configurabili.

Ciao

[nomorelogic]

scusate forse dico una baggianata ma...
il desktop non andrebbe diviso in scacchi e spedire solo gli scacchi differenti?

in questo caso, vado a senso ma bisogna sempre provare, forse lavorare con i bitmap per trovare le differenze è più veloce
poi ci pensa lo stream compresso

come la vedete?

[xinyiman]

Lavorare a scacchi lo credevo anche io, ma alla fine sull'udp non sono così sicuro che incida, sono da fare delle prove quando abbiamo l'infrastruttura di rete su cui trasmettere i dati. Fosse su TCP concordavo con te.

[DragoRosso]

Questo è il concetto dei compressori video (già fatti e stra super testati).

Però possiamo farlo anche a codice in pascal. Occorre suddividere la bitmap in memoria in "quadrotti" come accennavi tu e trasmettere solo i quadrotti differenti.

Accedendo alla bitmap in modalità regolare (scanline) conviene a questo punto lavorare per linee e trasmettere solo le linee differenti, invece dei "quadrotti".
Per linee intendo una serie lunga  di pixel quanto è l'ampiezza del desktop (ad esempio 1920 pixel).

Poi si può trasmetterne una si e una no (tipo TV) alternate, suddividere la linea ulteriormente .... etc ...

Occorre verificare il peso delle operazioni e quanto impattanti sono: ad esempio trasmettere 1920 x 3 byte o trasmettere 960 x 3 byte (cioè solo mezza linea) pesa di più in termini di elaborazione (devo fare due confronti invece che uno solo) o di trasmissione (dimezzo la trasmissione di dati nel caso di differenze).

Quanto è il cambiamento su una immagine desktop in termini percentuali e probabilistici:

1) se sul desktop ho la visualizzazione di un film, tanto vale che trasmetta tutta la bitmap, tanto avrò probabilmente un cambio continuo di tutte le righe della stessa, è inutile controllare e trasmette a pezzi l'immagine intera;

2) se sul desktop ho un "qualcosa" che varia in una zona medio / piccola allora probabilmente lo "spezzatino" avrà il suo effetto.

Ciao

[DragoRosso]

Lavorare a scacchi lo credevo anche io, ma alla fine sull'udp non sono così sicuro che incida, sono da fare delle prove quando abbiamo l'infrastruttura di rete su cui trasmettere i dati. Fosse su TCP concordavo con te.

In realtà trasmettere diversi dati più piccoli in UDP è (dovrebbe essere) un vantaggio. Come accennavo comunque i dati vengono frammentati (e anche vero che la frammentazione è a livello di sistema, di conseguenza veloce) e quindi trasmettere dati più piccoli e probabilmente meno frequentemente aiuta e migliora la trasmissione UDP.

Edit: dubbio legittimo inserito 

[nomorelogic]

cmq anche in un film non è detto che le linee siano sempre tutte differenti

ci sono sempre diversi contesti (streaming, videogame, video, video dei cellulari con le bande nere, ecc...)
secondo me si può mettere come opzione: scansione a scacchi o no

ma la scansione a scacchi, credo, vada implementata

[DragoRosso]

ma la scansione a scacchi, credo, vada implementata

Si, sono d'accordo. Deve essere una opzione per l'ottimizzazione.
Con riferimento a ciò, prima di implementare qualsiasi cosa pensiamo alla struttura di trasmissione.

Lavorare a scacchi lo credevo anche io, ma alla fine sull'udp non sono così sicuro che incida, sono da fare delle prove quando abbiamo l'infrastruttura di rete su cui trasmettere i dati. Fosse su TCP concordavo con te.

Io comunque posso mettere in piedi un semplice repeater nel server Internet con 4 porte fisse (per adesso, in attesa di implementare la dinamicità) per simulare un assistito e un assistente.

Una porta UDP e una TCP in ascolto (chiamiamole impropriamente server) e una porta UDP e TCP in ascolto (client) per la ritrasmissione dello stesso dato ricevuto allo stesso IP di ricezione (per adesso). Gli IP connessi (SERVER) verranno confrontati a quelli connessi (CLIENT) e i dati verranno reindirizzati se gli IP collimano. Per adesso implemento solo protocollo IPV4 e ovviamente i dati andranno sia da client e server sia da server a client.

La coda di listen sarà di 10 connessioni contemporanee massime per porta.

Internet a 1 Gigabit, MTU su Internet di 1500 byte (1448 byte dati), ma non è detto che l'MTU sia anche il vostro. Se volete provare la frammentazione, dovete eseguire un ping verso l'indirizzo interessato con le opzioni -f -l

Codice: [Seleziona]

 ping 217.198.132.230 -f -l 1448

Se vi genera un messaggio di avvertimento allora provate a diminuire il valore 1448.

Ciao

P.S.: appena pronto vi invio in chat privata le porte da usare.

[DragoRosso]

Ok server operativo su connessione UDP.

1) Invio un pacchetto alla prima porta, il pacchetto andrà perso;
2) Invio un pacchetto alla seconda porta, da ora in avanti tutti i dati ricevuti verranno inoltrati tra le due porte.

Timeout 30 secondi.
Le porte remote sono quelle di prima connessione (cioè quelle registrate con il primo pacchetto arrivato).
Se si devono cambiare porte occorre attendere 30 secondi prima di inviare dati (anzi almeno 45 secondi ... il timer di controllo esegue i test ogni 15 secondi).

Ciao

P.S.: massimo 10 connessioni da IP diversi contemporanee.

[DragoRosso]

Allego copia del RepeaterIP (è uno scheletro abbozzato anche se funzionante).

Ciao