Lavagna Condivisa

[Dylaniato]

Espongo brevemente il mio problema. Sono uno studente e con alcuno miei compagni abbiamo deciso di preparare come area di progetto una lavagna condivisa, uno spazio dove più utenti possano disegnare, modificare i disegni o scritte di altri utenti tutto rigorosamente in tempo reale.

Non voglio sorgenti già fatti naturalmente, vorrei solo dei consigli su da che parte cominciare, che linguaggio utilizzare ecc...

Conosciamo il C, Java, HTML e poco SQL, che però ci riserviamo di approfondire.

Grazie a tutti degli eventuali consigli!!!

[cionci]

Sinceramente non la vedo molto bene una browser app per questo genere di cose.
Quindi sicuramente ci vorrebbe un'applicazione client da realizzare con la sua GUI, per questo ti consiglio Java.
Poi per il resto ci sarebbe da studiarsi un po' l'architettura...

[Dylaniato]

quindi mi consiglieresti di utilizzare Java per realizzare l'applicazione client ed anche per connettersi alla rete e comunicare con altri client?

[Giullo]

l'app che vuoi sviluppare consiste in realtà di due componenti:

- un server che permetta la condivisione/modifica realtime dei contenuti della lavagna

- un client per "disegnare" ed interagire in genere con la lavagna

io ti consiglio di utilizzare flash + media server (un server macromedia che , tra le altre cose, supporta un procollo di messaging realtime) ..

il problema potrebbe essere il costo della licenza di media server (se nn ricordo male la versione developer supporta fino a 10 connessioni concorrenti, chiaramente per progetti non commerciali) e lo sviluppo in AS3 (che non rientra nel vostro bagaglio di conoscenza tecniche a quanto ho capito)

[variabilepippo]

quindi mi consiglieresti di utilizzare Java per realizzare l'applicazione client ed anche per connettersi alla rete e comunicare con altri client?

Sviluppare un progetto del genere in ANSI C è una bella mazzata, Java vi viene incontro fornendovi molte classi utilizzabili nella gestione della GUI, delle comunicazioni tra i client e della sincronizzazione degli eventi. In ogni caso, come detto anche da Cionci, il vero problema (ancora prima dell'implementazione) è quello di definire il tutto da un punto di vista architetturale...

[cionci]

Originariamente inviato da Dylaniato

quindi mi consiglieresti di utilizzare Java per realizzare l'applicazione client ed anche per connettersi alla rete e comunicare con altri client?

Se ho capito bene il senso che vuoi dare alla parola "lavagna" sì, un'applicazione web che sfrutta il browser avrebbe sia latenza molto alta che difficoltà realizzative ancora maggiori.
Per decidere quello che ci vuoi mettere nel mezzo ai client...dovresti fare un'attenta analisi dei requisiti e del campo di utilizzo. Ad esempio uno dei problemi nel decentrare il server sui client è quello di dover avere una porta aperta sul router.

[Dylaniato]

Originariamente inviato da Giullo

l'app che vuoi sviluppare consiste in realtà di due componenti:

- un server che permetta la condivisione/modifica realtime dei contenuti della lavagna

- un client per "disegnare" ed interagire in genere con la lavagna

io ti consiglio di utilizzare flash + media server (un server macromedia che , tra le altre cose, supporta un procollo di messaging realtime) ..

il problema potrebbe essere il costo della licenza di media server (se nn ricordo male la versione developer supporta fino a 10 connessioni concorrenti, chiaramente per progetti non commerciali) e lo sviluppo in AS3 (che non rientra nel vostro bagaglio di conoscenza tecniche a quanto ho capito)

la tua idea è da scartare perchè come da te detto, AS3 non rientra nelle nostre conoscienze, grazie comunque del consigliio

Originariamente inviato da variabilepippo

Sviluppare un progetto del genere in ANSI C è una bella mazzata, Java vi viene incontro fornendovi molte classi utilizzabili nella gestione della GUI, delle comunicazioni tra i client e della sincronizzazione degli eventi. In ogni caso, come detto anche da Cionci, il vero problema (ancora prima dell'implementazione) è quello di definire il tutto da un punto di vista architetturale...

spiegatevi meglio, in che senso dal punto di vista architetturale?

[Dylaniato]

Originariamente inviato da cionci

Se ho capito bene il senso che vuoi dare alla parola "lavagna" sì, un'applicazione web che sfrutta il browser avrebbe sia latenza molto alta che difficoltà realizzative ancora maggiori.
Per decidere quello che ci vuoi mettere nel mezzo ai client...dovresti fare un'attenta analisi dei requisiti e del campo di utilizzo. Ad esempio uno dei problemi nel decentrare il server sui client è quello di dover avere una porta aperta sul router.

assolutamente, non avevamo intenzione di utilizzare un browser, pensavamo più ad un software funzionante da sè, senza ausilio di browser... Scusate il doppio post!!!

[variabilepippo]

spiegatevi meglio, in che senso dal punto di vista architetturale?

Nel senso che prima di mettere mano al codice (indipendentemente dal linguaggio) bisogna progettare/decidere:

* L'architettura da adottare (client/server? client/client? ...?)
* Un protocollo di comunicazione per lo scambio dei dati
* Un meccanismo di sincronizzazione dei client
* La tipologia di applicazione da creare
* Un meccanismo di aggiornamento in "tempo-reale" dei disegni
* Le funzionalità di base (disegno a mano libera? Figure geometriche standard? ...)
* Le eventuali modalità di modifica dei disegni (un elemento grafico può essere spostato? Ridimensionato? ...?)

e via dicendo.

Dai uno sguardo a Sketch-o-matic è una delle tante applet del tipo "lavagna condivisa". Questo è un esempio "live".

[cionci]

Originariamente inviato da Dylaniato

spiegatevi meglio, in che senso dal punto di vista architetturale?

In base ai requisiti decidere quale sia la migliore architettura da scegliere...te ne dico diverse che possono fare al caso tuo, ognuna ha vantaggi e svantaggi.

1 - server centralizzato standalone realizzato in Java: i client si registrano sul server e tengono aperta una connessione TCP, il server comunica ai client gli aggiornamenti sulla connessione TCP aperta. Latenza media. I client non devono avere le porte aperte sul router (possono quindi essere terminali mobili che molto spesso non hanno la possibilità di aprire porte in ingresso).
Basta conoscere l'indirizzo del server che è fisso.

2 - server centralizzato sotto forma di applicazione web: sicuramente è più facile da realizzare rispetto ad un server standalone. I client si registrano sul server, recuperano la lista degli utenti dal server e recuperano gli aggiornamenti ricevuto dall'ultima connessione. Si possono usare terminali mobili. Basta conoscere l'indirizzo del server che è fisso.

3 - server distribuito realizzato nel client: ogni client fa anche da server, per aggiungersi alla "lavagna" bisogna conoscere l'indirizzo di almeno uno dei client per registrarsi. Un client invia i messaggi a tutti gli altri client duplicandoli. Latenza minima. I client devono tenere una porta aperta sul router.

4 - server distribuito e server centralizzato: come sopra, ma con in più un server centralizzato che tiene traccia degli utenti connessi alla lavagna (potrebbe anche fare l'autenticazione). La lista degli utenti con relativo ip viene recuperata periodicamente dal server centralizzato. Il server può essere di tipo 1 o di tipo 2 (in questo caso direi che 2 è più comodo). I messaggi di modifica della lavagna vengono inviati a tutti gli utenti in lista. I client devono avere una porta aperta sul router. Basta conoscere l'indirizzo del server centralizzato (è una politica simile a quella delle reti P2P). Latenza sempre minima.

[Dylaniato]

Originariamente inviato da variabilepippo

Nel senso che prima di mettere mano al codice (indipendentemente dal linguaggio) bisogna progettare/decidere:

* L'architettura da adottare (client/server? client/client? ...?)
* Un protocollo di comunicazione per lo scambio dei dati
* Un meccanismo di sincronizzazione dei client
* La tipologia di applicazione da creare
* Un meccanismo di aggiornamento in "tempo-reale" dei disegni
* Le funzionalità di base (disegno a mano libera? Figure geometriche standard? ...)
* Le eventuali modalità di modifica dei disegni (un elemento grafico può essere spostato? Ridimensionato? ...?)

e via dicendo.

Dai uno sguardo a Sketch-o-matic è una delle tante applet del tipo "lavagna condivisa". Questo è un esempio "live".

Originariamente inviato da cionci

In base ai requisiti decidere quale sia la migliore architettura da scegliere...te ne dico diverse che possono fare al caso tuo, ognuna ha vantaggi e svantaggi.

1 - server centralizzato standalone realizzato in Java: i client si registrano sul server e tengono aperta una connessione TCP, il server comunica ai client gli aggiornamenti sulla connessione TCP aperta. Latenza media. I client non devono avere le porte aperte sul router (possono quindi essere terminali mobili che molto spesso non hanno la possibilità di aprire porte in ingresso).
Basta conoscere l'indirizzo del server che è fisso.

2 - server centralizzato sotto forma di applicazione web: sicuramente è più facile da realizzare rispetto ad un server standalone. I client si registrano sul server, recuperano la lista degli utenti dal server e recuperano gli aggiornamenti ricevuto dall'ultima connessione. Si possono usare terminali mobili. Basta conoscere l'indirizzo del server che è fisso.

3 - server distribuito realizzato nel client: ogni client fa anche da server, per aggiungersi alla "lavagna" bisogna conoscere l'indirizzo di almeno uno dei client per registrarsi. Un client invia i messaggi a tutti gli altri client duplicandoli. Latenza minima. I client devono tenere una porta aperta sul router.

4 - server distribuito e server centralizzato: come sopra, ma con in più un server centralizzato che tiene traccia degli utenti connessi alla lavagna (potrebbe anche fare l'autenticazione). La lista degli utenti con relativo ip viene recuperata periodicamente dal server centralizzato. Il server può essere di tipo 1 o di tipo 2 (in questo caso direi che 2 è più comodo). I messaggi di modifica della lavagna vengono inviati a tutti gli utenti in lista. I client devono avere una porta aperta sul router. Basta conoscere l'indirizzo del server centralizzato (è una politica simile a quella delle reti P2P). Latenza sempre minima.

ringrazio entrambi per le risposte molto esaurienti, anche se alcuni termini mi sono sconosciuti.

Vedrò di documentarmi e parlarne con i miei professori...

@ cionci: sarei orientato + per la prima opzione, in quanto non voglio andare a complicare le cose con i router, secondo te è una buona soluzione?