Assistenza remota simil Team Viewer

[xinyiman]

E' un progetto che non ho più portato avanti. Da solo è troppo da fare. Ho però a quel tempo fatto un sacco di test e quindi mi è chiaro quali step occorrano per farlo bene. Ma dovrebbe diventare un progetto portato avanti a più persone perchè possa vedere la fine.

mi è tornato in mente questo vecchio thread
xinyiman, ci sono state evoluzioni?

[DragoRosso]

Siccome a me interessa direttamente anche per questioni lavorative e non solo ludiche, mi offro di affiancarti.

Si può costruire comunque lo scheletro portante a partire da quello che è stato fatto, poi le "features" e gli abbellimenti si possono aggiungere con calma ...

Ho un server in ufficio proiettato su internet con IP fisso (IPV6/IPV4 e DNS a fantasia) che possiamo usare come prima base di appoggio.

Ciao

[xinyiman]

Siccome a me interessa direttamente anche per questioni lavorative e non solo ludiche, mi offro di affiancarti.

Si può costruire comunque lo scheletro portante a partire da quello che è stato fatto, poi le "features" e gli abbellimenti si possono aggiungere con calma ...

Ho un server in ufficio proiettato su internet con IP fisso (IPV6/IPV4 e DNS a fantasia) che possiamo usare come prima base di appoggio.

Ciao

Bene, vediamo se riusciamo a tirare dentro anche qualcun'altro. Se arrivassimo a 4 (compresi noi due) saremmo a cavallo. Poi butto giù un paio di idee per la struttura portante e poi procediamo.

[xinyiman]

Comunque per chi vuole provarlo basta che scarica lo zip da: http://www.lazaruspascal.it/download_personali/korg_remote_desktop.zip

Poi va nella cartella bin/architettura della propria macchina/ e lanci l'eseguibile

Ovviamente vanno lanciate due istanze su due pc diversi nella stessa lna (al momento funziona solo in lan e solo la trasmissione del desktop remoto)

Nella textbox "Remote ip" bisogna mettere l'indirizzo ip della macchina con la quale si vuole interagire in lan (su tutte e due le istanze) poi sulla macchina da cui si vuole trasmettere premete sul pulsante invert epremete start. Sull'altra macchina compilate il campo "remote ip" e poi flaggate il check "jumbo packet" e premete start. Dovreste vedere il desktop remoto abbastanza bene.

[nomorelogic]

ok mi segno...
inutile che dica che il tempo è sempre poco ma lo strumento merita di essere portato avanti
lato linux le prove e le sistemazioni posso provare a farle io

cmq anche piano è sempre meglio che abbandonato no?

Edit
importante è che ci sia qualcuno che dia i compiti
giusto per evitare che ognuno prenda la sua strada
chiaramente propongo xinyiman visto che il progetto è suo

[xinyiman]

Datemi il tempo di rifare mente locale e nei prossimi giorni vi dico qualcosa al riguardo.

[DragoRosso]

importante è che ci sia qualcuno che dia i compiti
giusto per evitare che ognuno prenda la sua strada
chiaramente propongo xinyiman visto che il progetto è suo

Va bene, l'importante è definire i punti cardine del progetto in modo che si abbia le idee chiare su dove andare. Ciò anche per proporre e sondare le soluzioni più corrette.

Io mi occuperei della parte su Windows, fermo restando che dovremmo lavorare in stretta sintonia per le parti non comuni Windows / Linux / Mac / Android.

Scarico il progetto per capire dove è arrivato il ns. team leader.

Ciao

[nomorelogic]

visto che è ora di pranzo, ho una polpetta avvelenata...

si potrebbe pensare come client anche ad un browser?
chiaramente questo alla fine della fine, ma intanto possiamo tenerlo a mente

[xinyiman]

Al momento direi di no! Per come è impostato adesso. Se si vuole fare qualcosa di simile bisogna pensarlo diversamente. Io direi che i primi step sono.

1. Fare in modo che le funzionalità di base funzionino all'interno della lan (trasmissione diretta tra i due client)
2. Ripulire da quello che non serve/ottimizzare bene il codice
3. Fare in modo che la connessione non sia più diretta tra i due client ma metterci un server di mezzo che dirotti i pacchetti al client di destinazione
4. Testare il tutto su Win/Linux/Mac (io non ho più il mac e bisognerebbe trovare qualcuno che sia disposto ad aiutarci) - per il momento escluderei android

E già così c'è da divertirsi

[xinyiman]

Inoltre ad essere onesti se si vogliono fare le cose per bene, sarebbe tutta da riscrivere. Sicuramente riutilizzando il grosso del lavoro, ma sostituendo synapse con indy, che essendo di più alto livello si occupa lui di gran parte delle cose.

[DragoRosso]

Inoltre ad essere onesti se si vogliono fare le cose per bene, sarebbe tutta da riscrivere. Sicuramente riutilizzando il grosso del lavoro, ma sostituendo synapse con indy, che essendo di più alto livello si occupa lui di gran parte delle cose.

Alla parte su Indy ci penserei io. E' da anni che sviluppo con Indy, quindi non dovrebbe essere un problema.
Per il Mac si può combinare ....

1. Fare in modo che le funzionalità di base funzionino all'interno della lan (trasmissione diretta tra i due client)

OK, ma sarebbe meglio una volta testato questo passare subito alla fase con il terzo incomodo, ossia il server extra ... tanto la strada è quella a meno che qualcuno non abbia qualche coniglio nel cappello.
(oops non avevo fatto caso al punto (3) 
Un dettaglio immediato, visto che si accennava ai packet Jumbo: in genere non sono utilizzabili in quanto tali pacchetti vengono comunque frammentati a meno che TUTTE le nic non abbiano la funzionalità Jumbo Packet attiva (ma è disattiva per default e và settata in ogni singola scheda di rete).

Tenendo conto che la maggior parte dell'uso è tramite internet (o tramite bridge / router / switch / etc ...)  che non si possono sicuramente settare come và bene a noi direi che i Jumbo Packet potremmo lasciarli perdere (la definirei una features futuribile).

Inoltre dalle prove che effettuai diversi anni fà, è meglio un sistema che aderisca ad un MTU rilevato piuttosto che avere un trasmissione frammentata, soprattutto con pacchetti UDP.

Ma sono quisquilie ....

Ciao

[xinyiman]

Inoltre ad essere onesti se si vogliono fare le cose per bene, sarebbe tutta da riscrivere. Sicuramente riutilizzando il grosso del lavoro, ma sostituendo synapse con indy, che essendo di più alto livello si occupa lui di gran parte delle cose.

Alla parte su Indy ci penserei io. E' da anni che sviluppo con Indy, quindi non dovrebbe essere un problema.
Per il Mac si può combinare ....

1. Fare in modo che le funzionalità di base funzionino all'interno della lan (trasmissione diretta tra i due client)

OK, ma sarebbe meglio una volta testato questo passare subito alla fase con il terzo incomodo, ossia il server extra ... tanto la strada è quella a meno che qualcuno non abbia qualche coniglio nel cappello.

Un dettaglio immediato, visto che si accennava ai packet Jumbo: in genere non sono utilizzabili in quanto tali pacchetti vengono comunque frammentati a meno che TUTTE le nic non abbiano la funzionalità Jumbo Packet attiva (ma è disattiva per default e và settata in ogni singola scehda di rete).

Tenendo conto che la maggior parte dell'uso è tramite internet (o tramite bridge / router / switch / etc ...)  che non si può sicuramente settare come và bene a noi direi che i Jumbo Packet potremmo lasciarli perdere (la definirei una features futuribile).

Inoltre dalle prove che effettuai diversi anni fà, è meglio un sistema che aderisca ad un MTU rilevato piuttosto che avere un trasmissione frammentata, soprattutto con pacchetti UDP.

Ma sono quisquilie ....

Ciao

Allora direi di fare così, suddividiamo il progetto in aree più che in sistemi.

Area 1: sistema per la trasmissione di rete ( in prima istanza solo udp, in futuro anche TCP se udp non funzionasse)
Area 2: gestore del recupero dell'immagine screen su un client e visualizzazione dello stesso sull'altro client (ho già affrontato la cosa e potrei farlo io)
Area 3: crittografia

Il punto 1 dovrebbe essere gestito attraverso un server e dovrebbe permettere il trasferimento di stringhe e di stream
Il punto 2 me ne occupo io
Il punto 3 dovrebbe essere in AES256 bit.

Il client quando si collega al server dovrebbe scambiarsi la chiave aes256 con algoritmo a chiave asimmetrica (ho scritto degli esempi al riguardo) e poi dovrebbe cifrare solo il set di dati che serve per l'interscambio con la chiave aes256, perchè il corpo delle immagini e del testo viene cifrato con una crittografia sempre a 256 bit, ma con la chiave scambiata a voce con l'interlocutore dell'altro client (un po' come fa TeamViewer).

Questo a grandi linee

[xinyiman]

Una volta appurato che il sistema di comunicazione dei client passa correttamente nel server e il suo instradamento, dobbiamo capire come strutturare i messaggi che facciamo transitare al suo interno.

[DragoRosso]

Invece di AES256, proporrei SM4 a 128 bit (di cui ho postato i sorgenti in pascal). Dovrebbe essere più efficiente e meno esoso di risorse.

Anche questo comunque è un particolare. Invece provando quello che avevi fatto, dovremmo comunque sistemarlo per ridurre l'uso di CPU ... 20% è un pò troppo, anche 10% lo sarebbe.

Ciao

[xinyiman]

Invece di AES256, proporrei SM4 a 128 bit (di cui ho postato i sorgenti in pascal). Dovrebbe essere più efficiente e meno esoso di risorse.

Anche questo comunque è un particolare. Invece provando quello che avevi fatto, dovremmo comunque sistemarlo per ridurre l'uso di CPU ... 20% è un pò troppo, anche 10% lo sarebbe.

Ciao

Secondo me la strada maestra è riscriverlo da zero, tenendo buoni alcuni pezzi di codice per la gestione delle immagini per esempio.
La prima parte da fare è sicuramente la gestione della parte di rete, il resto lo si costruisce sopra.