[C#.Net] Più canali di comunicazione client/server

[Honik]

Salve a tutti..
cercherò di esporvi il mio problema in poche parole sperando che sia chiaro!
Ho un applicazione da me creata che permette lo scambio di stringhe da client a server.. per fare ciò mi son servito del TCP e mi son creato un socket.. ora avrei bisogno, in parallelo, di scambiare altre stringhe.. ma non sfruttando lo stesso canale.. vorrei creare un'altro flusso che lavori in parallelo e permetta lo scambio di altre stringhe.. come è possibile fare ciò???
Grazie e ciao

[ybla82]

Sicuramente devi organizzare la tua applicazione con un'architettura multithread.

Per aprire un altro canale tramite socket hai 2 soluzioni ( quelle che mi vengono in mente)

1)
lato server utilizzi lo stesso socket.
lato client apri diversi socket puntanto allo stesso indirizzo/porta.

Lato server entrarai più volte nel metodo accept che restituisce un nuovo socket col quale dialogare sul nuovo canale creato. A questo punto puoi avere tanti canali tante quante sono le nuove connessioni aperte lato client

2) lato server metti in attesa diversi socket ( su porte distinte) e lato client li chiami come vuoi.


nn mi viene in mente altro, e comunque direi che molto dipende da cosa devi realizzare.

[Honik]

OK ma perdonami.. cosi come riconosco tra client e server lo stesso socket???
Dovrei aprirli in "sequenza"?Prima uno poi l'altro?? e di conseguenza dall'altra parte accettare il socket...

comunque io ora come ora scambio stringhe per una chat.. vorrei scambiare altre stringhe in "parallelo" del tipo "informazioni profilo".. una sorta di messenger

[nuovoUtente86]

Un socket è una quadrupla formata da ip e porta sorgente-ip e porta destinazione.
Ad ogni chiamata accept(), fatta dal server, viene restituito il riferimento ad un nuovo Socket, da dare in pasto ad un Thread che svolgerà le operazioni dovute.

[Honik]

Continua a sfuggermi qualcosa...
mettiamo caso che mi creo 2 socket... come faccio a sapere quale socket è interessato nello scambio chat e quale nello scambio di altri dati??

probabilmente dovrei prima avviare un primo socket incaricato nella chat, e dopo avviare il secondo.. quindi deve essere una cosa sequenziale no?

[tomminno]

Continua a sfuggermi qualcosa...
mettiamo caso che mi creo 2 socket... come faccio a sapere quale socket è interessato nello scambio chat e quale nello scambio di altri dati??

probabilmente dovrei prima avviare un primo socket incaricato nella chat, e dopo avviare il secondo.. quindi deve essere una cosa sequenziale no?

Questo è compito del protocollo dati.
Al limite potresti usare 2 porte distinte, sulla falsa riga dell'FTP: su una passano i dati, sull'altra le informazioni accessorie.

[nuovoUtente86]

Il protocollo applicativo utilizzato, ovvero quello che materialmente passa come dati sui socket, devi stabilirlo tu in baso al funzionamento che l' applicazione deve avere.
Per farti un esempio, un FTP server accetta connessioni per l' instaurazione della sessione sulla porta 21 e poi ne apre una dati su una porta random che il client gli comunica.

[nuovoUtente86]

Ecco ti abbiamo dato in 2 la stessa risposta.

[Honik]

benissimo... quindi potrei impostare un socket su una porta specificata da me per quando riguarda la chat.. e magari l'altro lasciarlo random... ho capito bene?

[nuovoUtente86]

se la lasci random, la devi poi scambiare su un socket già esistente.

[Honik]

Ok.. allora magari creo 2 porte fisse e non dovrei avere problemi..
ma in questo modo se ho delle applicazioni esterne che lavorano già su quella porta che succede??

[nuovoUtente86]

utilizza porte non note.

[Honik]

Ragazzi.. ragionando bene ho notato che in questo modo avrei un grande numero di porte.. vorrei limitarmi ad una sola... quindi avevo pensato al fatto di mettere prima di ogni pacchetto un intestazione..
qualcosa del tipo
CHT "Ciao sono Honik" per le stringhe che riguardano le chat
INF "Informazioni profilo" per le stringhe che NON riguardano la chat..

per fare ciò come potrei procedere??
grazie

[nuovoUtente86]

un gran numero di porte perchè?
E se anche fosse, alla fine tu lavori sull' entità socket, che non è nient' altro che un oggetto, indipendentemente dai SAP di livello trasporto che ci stanno sotto.
Per quanto rigurda il tuo protocollo di chat, lo puoi gestire come meglio ti pare, in quanto quello è il contenuto binario dei segmenti TCP, a cui tu darai un significato.

[Honik]

non vorrei chiedere troppo.. ma potresti linkarmi o incollarmi un esempio su come potrei gestire la cosa?? Penso che mi verrebbe più chiara come spiegazione..

[nuovoUtente86]

Cosa non ti è chiaro?

[ybla82]

guarda io lo risolverei così.

Lato client.

-crei due socket che puntano allo stesso indirizzo.



Socket oChatSocket = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp);
Socket oInfoSocket = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp);



e quindi ti connetti.



oInfoSocket.Connect(m_sIndirizzo, m_iPorta);
oChatSocket .Connect(m_sIndirizzo, m_iPorta);




Lato Server.

-crei un socket e lo apri.


Socket oMainSocket = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp);

oMainSocket .Bind(new IPEndPoint(IPAddress.Any, m_iPortTCPModBus));
oMainSocket .Listen(50);



poi dentro un thread ci metti l'Accept.



Socket oSocketCommunication = oMainSocket .Accept();


Ogni volta che lato client fai una connect, lato server verrà eseguita la funzione accept che resituirà un oggetto socket. Questo socket lo puoi ora utilizzare per dialogare con il client (è un oggetto quindi che nn crei te, ma è il SO che ti dà questo oggetto per parlare). E' importante capire che lato client puoi creare connetterti con quanti socket vuoi, e ogni volta ti verrà resituito un oggetto Socket dal metodo Accept.
Quindi se fai 10 connect lato client, per 10 volte lato server otterrai un oggetto Socket dal metodo Accept.
Se poi va in debug, vedrai che l'esecuzione è sempr eferma sull'Accept: di fatto è "in ascolto per una nuova connessione".

Lato server, tutti ogni socket che hai ottenuto lo devi mettere in un thread dedicato, in cui chiamarei ciclicamente la funzione Receive.