Creazione di una chat Client/Server

[eriksingh15]

Salve a tutti,
vorrei creare un programma di chat in C# ben fatto, che dopo ho intenzione di ampliare incorporando funzionalità di chiamate voip (solo tra pc), ma ho molti dubbi su come la chat debba essere gestita, sopratutto a livello di client/server e le loro rispettive funzioni.

Potete darmi delle delucidazioni al riguardo, dandomi un'idea sull'argomento?

Grazie a tutti

[Daniels118]

Prima di tutto cercherei di capire bene che tipo di chat vuoi realizzare.
Ad esempio al momento mi vengono in mente questi tipi:
1) stanza - un luogo comune dove possono entrare diverse persone;
2) 1vs1 - si seleziona un interlocutore da un elenco;
3) gestita - come la stanza, ma c'è una persona che decide chi far parlare.
Poi ci sono altri aspetti, come la necessità di registrazione, la possibilità di vedere tutti gli utenti o solo quelli selezionati come amici e chi più ne ha più ne metta.

[starfred]

Ciao, il cuore di tutto è la progettazione.
Se, come ipotizzo, hai tempo a disposizione e non hai nessun cliente che ti assilla fai un bel modello a cascata (nei tempi attuali un po' vetusto ma secondo me è un ottimo chiarificatore) del tuo progetto che vuoi realizzare.
Ricorda sempre che il linguaggio di programmazione è solo uno strumento lo spartito musicale è la progettazione

[eriksingh15]

Grazie per le risposte.

Vorrei proprio realizzare una chat dove un utente può registrarsi e avere più contatti, che poi può vedere quando essi vengono online.

Però ho le idee molto confuse al riguardo.

Sono riuscito a realizzare una chat di una persona che comunica con un'altra, ma è molto semplice e non prevede l'uso di un server, ma i messaggi vanno direttamente da un pc all'altro (funziona solo nel locale).

E quindi non mi è neanche tanto chiara la funzione del server. Qualcuno può spiegarmi? Grazie

[OoZic]

se per un momento decidessi di abbandonare c# in favore di un approccio più moderno (e per certi aspetti migliore) ti suggerirei:
- websocket per la parte chat, puoi implementare una chat in realtime con uno sforzo "minimo".
- webrtc per la parte voip

linguaggio utilizzato javascript sia lato client che server (node.js).

[Shirov]

...oppure il linguaggio Opa, con tanto di esempio già fatto
https://github.com/MLstate/opalang/wiki/Hello,-chat

[OoZic]

Originariamente inviato da Shirov

...oppure il linguaggio Opa, con tanto di esempio già fatto
https://github.com/MLstate/opalang/wiki/Hello,-chat

a quel punto meglio Meteor
https://www.meteor.com/

ma credo sia troppo "in la" per il thread starter

[tomminno]

Originariamente inviato da OoZic

se per un momento decidessi di abbandonare c# in favore di un approccio più moderno (e per certi aspetti migliore) ti suggerirei:
- websocket per la parte chat, puoi implementare una chat in realtime con uno sforzo "minimo".
- webrtc per la parte voip

linguaggio utilizzato javascript sia lato client che server (node.js).

In cosa Javascript (e l'utilizzo forzato di un browser) potrebbe essere migliore di un linguaggio come C# (ma poteva essere pure Java)?
Per realizzare la chat e l'autenticazione dell'utente il solo Javascript non ti basta, hai bisogno di una parte server. La implementi sempre in Javascript? Quanti hosting trovi che ti possano fornire l'ambiente per far girare node.js lato server? Come facilità di Debug come si rapportano le 2 soluzioni?
Performance?

Per la UI Javascript non ti basta hai bisogno di conoscere l'html.
Questo comporta che devi lottare con le compatibilità tra i vari browser, imparare ad usare jquery, bootstrap...

Definire più moderno e forse migliore, un approccio provato e abbandonato dai più (comunque solo per la parte di interfaccia) per enormi problemi di performance, mi pare un azzardo.

[OoZic]

Originariamente inviato da tomminno

In cosa Javascript (e l'utilizzo forzato di un browser) potrebbe essere migliore di un linguaggio come C# (ma poteva essere pure Java)?

Per il fatto che scrivi in UN solo linguaggio UNA sola app che può funzionare su qualsiasi computer/smartphone/tablet/device che abbia un browser.

Solo per questo motivo ci si potrebbe fermare qui.

Originariamente inviato da tomminno

Per realizzare la chat e l'autenticazione dell'utente il solo Javascript non ti basta, hai bisogno di una parte server.

Si l'ho scritto nel mio post che ti serve anche lato server javascript (nodejs)

Originariamente inviato da tomminno

La implementi sempre in Javascript? Quanti hosting trovi che ti possano fornire l'ambiente per far girare node.js lato server?

https://www.heroku.com/
https://www.nodejitsu.com/

sono i più famosi e "immediati" nel senso che ti danno una PaaS quindi devi solo caricare la tua app per farla funzionare e non preoccuparti praticamente di nient'altro.

Originariamente inviato da tomminno

Come facilità di Debug come si rapportano le 2 soluzioni?

Non saprei rispondere su questo punto sinceramente.

Originariamente inviato da tomminno

Performance?

Sono sempre di più le big company che adottano Node, specialmente per le performance.
https://www.paypal-engineering.com/2...-js-at-paypal/
Sono numeri che fanno impressione.

Se poi parliamo di una chat è probabilmente un ambito dove Node.js è un mostro abbinato a websockets.

Originariamente inviato da tomminno

Per la UI Javascript non ti basta hai bisogno di conoscere l'html.
Questo comporta che devi lottare con le compatibilità tra i vari browser, imparare ad usare jquery, bootstrap...

Seriamente nel 2014 l'html o un framework come bootstrap può essere paragonato in difficoltà a programmare in un linguaggio come C# o Java?
Mi viene un pò da ridere su questo

Originariamente inviato da tomminno

Definire più moderno e forse migliore, un approccio provato e abbandonato dai più (comunque solo per la parte di interfaccia) per enormi problemi di performance, mi pare un azzardo.

La realtà a me sembra totalmente diversa, tanto per fare un esempio ieri GitHub ha annunciato che stanno lavorando a un nuovo editor sviluppato totalmente in javascript e basato su node-webkit...e volendo la lista di esempi è lunghissima.

Direi quindi che quello che hai scritto è più una tua sensazione o pensiero che (per fortuna) non corrisponde alla realtà.

Porta qualche fonte a sostegno della tua idea e possiamo parlarne.

[eriksingh15]

Grazie per le risposte.

Io comunque conterei di fare un progetto basato sul modello client/server, e le soluzioni che mi avete proposto mi sembrano buone.

Però vorrei capire di più sulla funzione del server in una chat: a cosa serve? Ho letto che serve per l'autenticazione, e poi? Per stabilire le connessioni?

Voglio sciogliere i dubbi su questo aspetto della chat.

Grazie mille a tutti!

[Daniels118]

Il server gestisce i dati degli utenti e l'autenticazione. E' indispensabile che i dati si trovino su un server gestito da un terzo per evitare che gli utenti possano appropriarsi dei dati di altri utenti o falsificare la propria identità.

Poi c'è l'aspetto tecnologico.
Le attuali tecnologie standard non consentono di instaurare una connessione tra due "pari", deve esserci sempre un server ed uno o più client.
Anche volendo attribuire arbitrariamente il ruolo di server ad uno dei partecipanti si incontrerebbero notevoli difficoltà (indirizzo da contattare variabile, firewall, ecc.).

[ingframin]

Originariamente inviato da eriksingh15

Grazie per le risposte.

Io comunque conterei di fare un progetto basato sul modello client/server, e le soluzioni che mi avete proposto mi sembrano buone.

Però vorrei capire di più sulla funzione del server in una chat: a cosa serve? Ho letto che serve per l'autenticazione, e poi? Per stabilire le connessioni?

Voglio sciogliere i dubbi su questo aspetto della chat.

Grazie mille a tutti!

Il fatto e' che tu hai posto una domanda semplice e sono partiti i soliti super agguerriti super esperti informatici.

Il server ti serve o non ti serve in base a come strutturi la rete ad alto livello.
La chat e' come se fosse una rete a se stante (tu utente non vedi i protocolli che stanno sotto).
Quindi: 2 o piu' computer che comunicano tra loro direttamente formano una rete peer-to-peer.
Nessun server o altro in mezzo. Fantastica ma molto complessa da gestire.
Es. La chat che hai fatto tu.

Soluzione client - server:
I computer coinvolti nella chat mandano i messaggi a un server centrale che poi provvede a distribuirli ai membri della chat. Es. IRC.

La soluzione col server in mezzo, a parte tutte le menate sui dati, ti serve innanzitutto per semplificare la gestione della chat, per fare si che gli utenti possano essere facilmente a conoscenza dello stato degli altri in tempo reale senza mandare 100000000000000000000 pacchetti in rete per chiedere a tutti se ci sono o no, per facilitare lo scambio di files e per mantenere un datalog di cio' che avviene o addirittura registrare la chat.

Il server normalmente ha sopra un programma che gestisce le connessioni e una base di dati (o un sistema alternativo, ma prendiamo il db che e' il piu' semplice).
Immagina di avere utente A, utente B e il server.

Come funziona una sessione di chat?

1) A e B si autenticano col server ed entrano in chat -> Il server costruisce una tabella che rappresenta la stanza e (di solito) informa A e B che entrambi sono collegati alla "stanza"

2) A scrive un messaggio -> Il server prende il messaggio, lo salva in tabella e comunica ad A e B l'aggiornamento della tabella -> B vede il messaggio a video

3) B risponde -> Vedi punto due al contrario

e cosi' via...

Questo meccanismo fa si che i terminali di A e B siano super semplici da realizzare e tutta l'elaborazione e' fatta dal server.

La chat diretta e' invece l'analogo di una telefonata: sta a chi parla informarsi costantemente sullo stato di chi e' dall'altra parte ovvero "mantenere una connessione aperta" -> protocollo sincrono.

Se un server memorizza i messaggi la consegna non deve avvenire per forza immediatamente -> protocollo asincrono.

Spero di averti chiarito un poco le idee.

Se ti interessa un po' la teoria ti consiglio di leggere il libro di Tanenbaum "Reti di Calcolatori" oppure "Reti di Telecomunicazione" di Achille Pattavina (un poco palloso ma super completo).

Buon divertimento

[eriksingh15]

Originariamente inviato da ingframin

Il fatto e' che tu hai posto una domanda semplice e sono partiti i soliti super agguerriti super esperti informatici.

Il server ti serve o non ti serve in base a come strutturi la rete ad alto livello.
La chat e' come se fosse una rete a se stante (tu utente non vedi i protocolli che stanno sotto).
Quindi: 2 o piu' computer che comunicano tra loro direttamente formano una rete peer-to-peer.
Nessun server o altro in mezzo. Fantastica ma molto complessa da gestire.
Es. La chat che hai fatto tu.

Soluzione client - server:
I computer coinvolti nella chat mandano i messaggi a un server centrale che poi provvede a distribuirli ai membri della chat. Es. IRC.

La soluzione col server in mezzo, a parte tutte le menate sui dati, ti serve innanzitutto per semplificare la gestione della chat, per fare si che gli utenti possano essere facilmente a conoscenza dello stato degli altri in tempo reale senza mandare 100000000000000000000 pacchetti in rete per chiedere a tutti se ci sono o no, per facilitare lo scambio di files e per mantenere un datalog di cio' che avviene o addirittura registrare la chat.

Il server normalmente ha sopra un programma che gestisce le connessioni e una base di dati (o un sistema alternativo, ma prendiamo il db che e' il piu' semplice).
Immagina di avere utente A, utente B e il server.

Come funziona una sessione di chat?

1) A e B si autenticano col server ed entrano in chat -> Il server costruisce una tabella che rappresenta la stanza e (di solito) informa A e B che entrambi sono collegati alla "stanza"

2) A scrive un messaggio -> Il server prende il messaggio, lo salva in tabella e comunica ad A e B l'aggiornamento della tabella -> B vede il messaggio a video

3) B risponde -> Vedi punto due al contrario

e cosi' via...

Questo meccanismo fa si che i terminali di A e B siano super semplici da realizzare e tutta l'elaborazione e' fatta dal server.

La chat diretta e' invece l'analogo di una telefonata: sta a chi parla informarsi costantemente sullo stato di chi e' dall'altra parte ovvero "mantenere una connessione aperta" -> protocollo sincrono.

Se un server memorizza i messaggi la consegna non deve avvenire per forza immediatamente -> protocollo asincrono.

Spero di averti chiarito un poco le idee.

Se ti interessa un po' la teoria ti consiglio di leggere il libro di Tanenbaum "Reti di Calcolatori" oppure "Reti di Telecomunicazione" di Achille Pattavina (un poco palloso ma super completo).

Buon divertimento

Grazie mille per i chiarimenti, è più o meno come pensavo e quindi ora ho delle conferme.

Il fatto è che sono uno studente di quinta ITIS Informatico (progetto "Abacus") e vorrei iniziare questo progetto con un mio compagno di classe.

L'idea è di fare un programma di chat con un architettura client/server, e poi ampliarlo con funzionalità voip.

Ora devo capire come implementare la mia idea, visto che in partenza volevo farlo in C# ma certi utenti hanno proposto delle idee interessanti, come il websocket, che mi sembra più veloce da realizzare.

Per quanto riguarda la programmazione, da quello che ho capito la parte server sarà molto più complessa della parte client, giusto?

Ora ho dei dubbi sul fatto che il progetto sia alla mia portata

[ingframin]

Originariamente inviato da eriksingh15

Grazie mille per i chiarimenti, è più o meno come pensavo e quindi ora ho delle conferme.

Il fatto è che sono uno studente di quinta ITIS Informatico (progetto "Abacus") e vorrei iniziare questo progetto con un mio compagno di classe.

L'idea è di fare un programma di chat con un architettura client/server, e poi ampliarlo con funzionalità voip.

Ora devo capire come implementare la mia idea, visto che in partenza volevo farlo in C# ma certi utenti hanno proposto delle idee interessanti, come il websocket, che mi sembra più veloce da realizzare.

Per quanto riguarda la programmazione, da quello che ho capito la parte server sarà molto più complessa della parte client, giusto?

Ora ho dei dubbi sul fatto che il progetto sia alla mia portata

Quello che vuoi fare tu è massiccio e richiede un sacco di lavoro. Il linguaggio è francamente l'ultimo dei problemi e molto dipende dai gusti e dalle attitudini personali. Fosse per me ad esempio farei tutto in Python, magari usando Tornado o Twisted per la parte server.

Voip poi richiede tanta banda e l'uso di algoritmi per nulla banali di compressione e trasmissione dati.

Onestamente la chat la vedo abbondantemente alla tua portata con qualunque linguaggio (è un progetto didattico, non devi servire migliaia di utenti) mentre la parte voip secondo me è troppo per due persone da sole soprattutto se ancora a scuola e a digiuno di reti, protocolli e modelli di traffico.

Non demordete comunque, anche se doveste fallire di sicuro imparerete mille mila cose che non avreste comunque modo di leggere da nessuna parte.

[OoZic]

Originariamente inviato da ingframin

Voip poi richiede tanta banda e l'uso di algoritmi per nulla banali di compressione e trasmissione dati.

Si e no, nel senso che utilizzando WebRTC ad esempio non ti devi preoccupare di algoritmi compressione o quant'altro.

Detto questo comunque dipende da cosa vuol tirar fuori da questo progetto l'utente.

Io fossi in lui visto che è ancora molto giovane e con voglia di imparare mi concentrerei su qualcosa di "moderno" che possa in un futuro portargli un lavoro.

[clockover]

Originariamente inviato da OoZic

Io fossi in lui visto che è ancora molto giovane e con voglia di imparare mi concentrerei su qualcosa di "moderno" che possa in un futuro portargli un lavoro.

Tipo?

Inviato da una supercazzola ed un Nexus 5 scappellato a sinistra.. con senso unico

[Daniels118]

Originariamente inviato da OoZic

Si e no, nel senso che utilizzando WebRTC ad esempio non ti devi preoccupare di algoritmi compressione o quant'altro.

Detto questo comunque dipende da cosa vuol tirar fuori da questo progetto l'utente.

Io fossi in lui visto che è ancora molto giovane e con voglia di imparare mi concentrerei su qualcosa di "moderno" che possa in un futuro portargli un lavoro.

Didattica e lavoro non vanno molto d'accordo, se ho intuito bene è un progetto per l'esame di stato, e non penso che scatole nere all'avanguardia diano molto valore all'operato dello studente.

[tomminno]

Originariamente inviato da OoZic

Per il fatto che scrivi in UN solo linguaggio UNA sola app che può funzionare su qualsiasi computer/smartphone/tablet/device che abbia un browser.

Solo per questo motivo ci si potrebbe fermare qui.

Non è vero che scrivi in un solo linguaggio, sono almeno 3: Javascript, html e CSS. Di ognuno devi conoscere la sintassi e le peculiarità.

Poi che devi stare dietro alla compatibilità con tutti i browser e per tutti i formati. Devi creare interfacce responsive altrimenti ottieni un software inusabile su alcune piattaforme.
Considera poi che girando nel browser la tua app non può eseguire chiamate cross site, se non affidandosi ad html5 e ai browser che lo supportano.
Infine non tutti i servizi lato server supportano il CORS, mi sono trovato a dover cambiare completamente applicativi da puramente client a client+server perchè il server S3 compatibile di turno non supportava chiamate CORS.

Unico protocollo supportato: http

Nel caso della chat, l'invio di messaggi direttamente ad un altro client lo vedo problematico.

Non saprei rispondere su questo punto sinceramente.

Il debug non è proprio comparabile, test automatici nemmeno, entrambi punti a favore dei linguaggi server-side. I pochi profiler che trovi in giro sono limitati allo specifico motore di javascript su cui gira lo script. Che proprio perchè è uno script potrebbe andare benissimo su V8, ma non su SpiderMonkey...

Sono sempre di più le big company che adottano Node, specialmente per le performance.
https://www.paypal-engineering.com/2...-js-at-paypal/
Sono numeri che fanno impressione.

In passato chi ha seguito la strada delle app mobile in javascript (es usando Phonegap) è tornato indietro sulla via nativa. Il caso più eclatante è stato quello di facebook.

Se poi parliamo di una chat è probabilmente un ambito dove Node.js è un mostro abbinato a websockets.

Ma una chat non è solo scambio dati! Dovrai visualizzarli questi dati, forse dovrai registrarli su un db per evitare di perdere tutto. L'interfacciamento di node.js verso i vari database è un tantino carente, sicuramente non al livello di linguaggi quali C#, Java o PHP.

Seriamente nel 2014 l'html o un framework come bootstrap può essere paragonato in difficoltà a programmare in un linguaggio come C# o Java?
Mi viene un pò da ridere su questo

Ci puoi scommettere!
E' molto più difficile fare una interfaccia con html e bootstrap che non con C#, pure se ci metti WPF.
Anche solo per la comodità degli editor visuali...

Ti faccio solo un esempio stupidissimo di funzionalità: la riproduzione di un filmato. Su un desktop (esteso anche al mobile) posso usare un qualunque formato supportato dal sistema operativo, sul web ti devi limitare a quanto supportato dal browser per html5 (ogni browser fa storia a sè) o flash (che nel mobile praticamente non è da considerare). E che succede se non hai il filmato in uno di questi formati?
Fai transcodifica video con Javascript?

La realtà a me sembra totalmente diversa, tanto per fare un esempio ieri GitHub ha annunciato che stanno lavorando a un nuovo editor sviluppato totalmente in javascript e basato su node-webkit...e volendo la lista di esempi è lunghissima.

Bisogna capire se è un editor online oppure un editor desktop...
Nel caso sia anche desktop andrebbe poi provato a confronto con tradizionali editor in performance nella ricerca di un testo nei file, nell'apertura di un file di grosse dimensioni ecc...

Direi quindi che quello che hai scritto è più una tua sensazione o pensiero che (per fortuna) non corrisponde alla realtà.

Porta qualche fonte a sostegno della tua idea e possiamo parlarne.

Mah il mondo delle app ha abbandonato la chimera dello sviluppo Javascript. Tanti sono rimasti scottati dalla moda di usare Javascript perchè era tutto bello che uguale in ogni piattaforma, poi la realtà è un'altra: scarse performance, lag, limitazioni tipiche dell'html, necessità di adattamento alle singole piattaforme che risulta comunque necessario... E quindi torni a sviluppare in nativo.

[ingframin]

Originariamente inviato da OoZic

Si e no, nel senso che utilizzando WebRTC ad esempio non ti devi preoccupare di algoritmi compressione o quant'altro.

Detto questo comunque dipende da cosa vuol tirar fuori da questo progetto l'utente.

Io fossi in lui visto che è ancora molto giovane e con voglia di imparare mi concentrerei su qualcosa di "moderno" che possa in un futuro portargli un lavoro.

Uaglio', l'amico del sole che ha iniziato il post fa il quinto superiore...
Ora ha la possibilita' di studiare e imparare senza pressione addosso, poi sara' costretto a usare quello che gli imporra' l'azienda.
Conta pure che capire la teoria ti rende molto piu' versatile che non imparare il tool del momento.
Metti che tra 1 anno uscira' la moda di programmare in linguaggio cow: Se chi programma conosce le basi non avra' troppe difficolta' a portare i concetti in un altro linguaggio, se e' una scimmia da codice addestrata all'uso del tool alla moda e basta patira' parecchio per saltare sul nuovo treno.
Onestamente: meglio una cosa piu' semplice ma che ti fa capire la teoria che non una cosa ricca di funzionalita' a scatola chiusa.
Almeno a 18 anni. Poi da grande hai voglia a usare robaccia a scatola chiusa...

[Daniels118]

A tal proposito posso suggerire di ripercorrere una strada che ho seguito tempo fa, implementando da zero un sistema di teleconferenza voip multiutente con compressione adpcm, oltre ad aver ottenuto un ottimo (e redditizio) risultato, è stato anche molto educativo.