Assistenza remota simil Team Viewer

[nomorelogic]

quindi per ora il TSendPingThread non servirebbe ma è in previsione di "sentire" se c'è il server per l'interscambio delle informazioni di connessione?

[xinyiman]

No il TSendPingThread  serve per creare l'UDP hole punching ovvero il modo con cui non farsi fermare dal firewall.

Inoltre è quello che serve al client per capire se la connessione è attualmente su oppure no.

[xinyiman]

Allora qualcuno ha avuto modo di pensare alla mia proposta di portare avanti tale progetto?

[guest1752]

ciao, a me piace molto l'idea, ma ho poco poco tempo questo periodo e ho visionato il codice molto velocemente.
Lo scambio di immagini potrebbe essere una parte interessante per me:
stavo ragionando ieri su un progetto di tanti anni fa in delphi dove in pratica giocavo con le GDI+ e il device context di windows ecc... ec.. .comunque alla fine l'idea che ho è che per minimizzare lo scambio dei dati si potrebbe dividere lo schermo in n quadrati e far passare solo le zone dello schermo diverse, come dicevi te. Interesssante pero.....

[nomorelogic]

il progetto è interessante
si potrebbe dare una mano ma non posso fare di sicuro il manutentore del progetto

[xinyiman]

Si accettano anche aiuti, posso anche mantenerlo io ma avere una mano da voi. Ovviamente non in questo momento, ma quando saremo tutti un po meno pressati dal lavoro.

[nomorelogic]

si, direi che aspettare tempi meno pressanti è un bene per tutti
intanto potresti provare a dividerlo in sottoprogetti
esempio:
- struttura principale (es: gestione thread per video, chat, scambio file, ...)
- gestione hole punching
- gestione astratta invio/ricezione dati come stringa
- gestione invio/ricezione video
- gestione invio/ricezione chat
- gestione invio/ricezione file

in questo modo sarà più facile dare una mano per chi potrà

[guest1752]

si, direi che aspettare tempi meno pressanti è un bene per tutti
intanto potresti provare a dividerlo in sottoprogetti
esempio:
- struttura principale (es: gestione thread per video, chat, scambio file, ...)
- gestione hole punching
- gestione astratta invio/ricezione dati come stringa
- gestione invio/ricezione video
- gestione invio/ricezione chat
- gestione invio/ricezione file

in questo modo sarà più facile dare una mano per chi potrà

in effetti è un'ottima idea dividerlo in sottoprogetti.
Mi stavo chiedendo, visto che ci sono già programmi famosi che fanno egregiamente il loro lavoro, bisognerebbe pensare a delle features che gli altri non hanno ( non mi viene in mente niente per ora ) e  definire quale sia sistema il sistema operativo target.

Nel caso di un sistema operativo come Windows si potrebbero usare delle api dirette per renderlo veloce, ma se il progetto deve girare anche su linux o altro bisogna ragionare bene sulla struttura del progetto.
Cosa ne pensate?

[xinyiman]

Il codice deve essere mantenibile e multipiattaforma, quindi escludo a priori api del singolo sistema operativo se proprio non sono costretto, tipo il controllo del mouse per cocoa.

Per il discorso cosa fare per renderlo appetibile il gioco è molto semplice: gratuito + social.

Il renderlo social lo spiegherò quando sarà il momento, non vorrei che qualcuno mi rubasse l'idea solo leggendola sul forum.

[nomorelogic]

Il codice deve essere mantenibile e multipiattaforma, quindi escludo a priori api del singolo sistema operativo se proprio non sono costretto, tipo il controllo del mouse per cocoa.

che sia multipiattaforma è un bene, forse oggi le app che non sono tali non hanno più tanto senso
per il mouse per cocoa, se non ci sono alternative valide, nulla ti vieta di usare le api dedicate: basta che incapsuli il codice dedicato con delle direttive

[xinyiman]

Si anche io penso che le app singolo OS non hanno più molto senso. Detto questo sono riuscito ad ottenere qualcosa con il mouse di cocoa solo con il c. Ma se non ricordo male si possono inglobare delle librerie c in lazarus. Nella peggiore delle ipotesi faccio eseguire i comandi come un eseguibile esterno. Però diciamo che prima è importante che funzioni su win e linux con il pacchetto standard di lazarus. Poi quando abbiamo sistemato quello io simulo le stesse cose anche per cocoa. Magari la gestione del mouse e della tastiera l'astraiamo così da poterlo gestire meglio.

[mbisax]

Salve,
nessun avanzamento di questo interessante progetto ?
Anche io, come xinyiman, penso da anni a un progetto simile per poter controllare la buona esecuzione dei prg installati presso i nostri clienti ma ho sempre desistito per mancanza di tempo.

[xinyiman]

Ciao, il progetto al momento è fermo, avevo settimane fa ripreso il tutto riscrivendolo da zero. Per il momento ho solo riscritto la parte per la condivisione dello schermo.

1. Ho suddiviso lo schermo in 4 parti
2. Trasmetto le singole 4 parti in rete con il protocollo UDP
3. Quando ricevo l'immagine parziale lo ricompongo nel mio programma

Funziona su mac e su windows, ma non su ubuntu. Non ha alcun tipo di crittografia al momento e ho fatto test solo in rete locale. Magari in futuro lo riprendo, ora sono davvero oberato di lavoro.

[mbisax]

Grazie per aver risposto così rapidamente.
Ho provato la versione che avevi postato e funziona. Una buona base di partenza sulla quale si può lavorare per aggiungere ciò che manca. Se hai riscritto buona o tutta parte del programma conviene aspettare che tu renda disponibile la nuova versione prima di metterci mano.
Avendo affrontato il problema già tempo fa per una necessità molto più ridotta rispetto a quella che hai in animo di produrre, occorre trasmettere su un layer HTTP per passare attraverso il firewall che, normalmente non chiude la porta 80 dedicata al web: a quello che so, Teamviewer e altri prodotti simili sfruttano questa tecnica.

[xinyiman]

Guarda penso proprio che TeamViewer funziona con la tecnica dell' Udp Hole Pouching. Comunque non ho nessun problema a condividere l'ultima versione.

Attenzione solo ad una cosa, le custom options

-dUseCThreads
-dNoWriteDebug
-dGetScreenInMainThread

La prima non va toccata, la seconda mi serviva per dare del debug usando la console, basta cambiarla in -dWriteDebug.
La terza invece se rimossa fa si che il desktop venga preso nei singoli thread (funziona su mac os e windows) mentre con -dGetScreenInMainThread dovrebbe funzionare con ubuntu (cosa che al momento non avviene).

Inoltre in uMain ci sono queste due costanti


const
     COUNT_ROW_ZONE_SCREEN = 1;
     COUNT_COL_ZONE_SCREEN = 1;

che servono a cambiare il numero di parti con cui suddivido il monitor e quindi il numero di thread secondari. Provate ad impostarlo su


const
     COUNT_ROW_ZONE_SCREEN = 2;
     COUNT_COL_ZONE_SCREEN = 2;