[C/C++] Guida socket

[17Qwerty71]

Avrei in progetto un programma che comunica tramite un'altro attraverso le socket, avete dei buoni tutorial (o guide) da propormi?
Premetto che sulle socket non conosco ancora nulla

[cj++]

ma lavori su unix o win?

[17Qwerty71]

Originariamente inviato da cj++

ma lavori su unix o win?

Win

[Fenomeno85]

allora per windows esiste msdn http://msdn.microsoft.com/library/de...k/socket_2.asp

Non esiste nulla di + completo rispetto a msdn

~§~ Sempre E Solo Lei ~§~

[-fidel-]

Originariamente inviato da Fenomeno85

allora per windows esiste msdn http://msdn.microsoft.com/library/de...k/socket_2.asp

Non esiste nulla di + completo rispetto a msdn

~§~ Sempre E Solo Lei ~§~

Per Win sicuramente, però nel caso dei socket mi pare opportuno prima uno studio sul meccanismo di comunicazione client-server (o p2p ma meglio lasciare p2p per dopo)
17Qwerty71, a teoria dei socket come stai messo?

[-fidel-]

Mi quoto da solo...

Originariamente inviato da -fidel-

17Qwerty71, a teoria dei socket come stai messo?

ho appena riletto il tuo primo messaggio. Vedo di cercarti qualche tutorial sul meccanismo dei socket sul web (altrimenti ti passo il materiale che ho ereditato dai corsi dell'università, ma meglio di no )

[17Qwerty71]

Originariamente inviato da -fidel-

Mi quoto da solo...



ho appena riletto il tuo primo messaggio. Vedo di cercarti qualche tutorial sul meccanismo dei socket sul web (altrimenti ti passo il materiale che ho ereditato dai corsi dell'università, ma meglio di no )

Grazie, mi farebbe piacere dare uno sguardo alla teoria di comunicazione tra due dispositivi
Il programmino in questione comunica con un'altro tramite la rete lan, non so' se può tornare utile come informazione

[-fidel-]

Uff sono di nuovo scomparsi i messaggi scritti in mattinata!!
Ti avevo messo due link, ora li devo cercare di nuovo...

[71104]

Originariamente inviato da 17Qwerty71

Grazie, mi farebbe piacere dare uno sguardo alla teoria di comunicazione tra due dispositivi
Il programmino in questione comunica con un'altro tramite la rete lan, non so' se può tornare utile come informazione

ah be', se lavori su una rete LAN allora puoi usare le named pipes oppure le mailslot che sono secondo me più semplici dei sockets; se invece pensi che in futuro dovrai far comunicare i tuoi programmi anche attraverso Internet allora è meglio che usi i sockets e che al momento opportuno ti studi le estensioni aggiunte da Microsoft nei Windows Sockets 2 per lavorare con protolli diversi.

EDIT: io una volta ho realizzato un programma per chattare su reti LAN che usava le mailslot; se vuoi ti passo i sorgenti (è fatto in Visual C++ 6 con MFC).
comunque ricordo che su alcune reti il programma aveva un problema che ritengo fosse dovuto a qualche malfunzionamento delle mailslots contro i quali ti devo avvisare: a volte (non so quando e non so perché) le mailslot riceventi ricevono gli stessi messaggi due o tre volte, sono abbastanza sicuro che non dipendesse dal mio programma (ho controllato molto approfonditamente con l'aiuto del debugger); mi era venuto in mente di risolvere la questione usando dei transaction IDs nei miei messaggi (il programma ricevente doveva ignorare messaggi con TrID uguale a quello di un messaggio precedente), ma alla fine non l'ho più fatto per pigrizia
attualmente il mio programma funziona alla perfezione tranne che su alcune reti i messaggi di chat arrivano 2 o raramente 3 volte

[17Qwerty71]

Originariamente inviato da -fidel-

Uff sono di nuovo scomparsi i messaggi scritti in mattinata!!
Ti avevo messo due link, ora li devo cercare di nuovo...

Mi farebbe piacere perchè mi sono scordato di salvare il link nei segnalibri

Originariamente inviato da 71104

ah be', se lavori su una rete LAN allora puoi usare le named pipes oppure le mailslot che sono secondo me più semplici dei sockets; se invece pensi che in futuro dovrai far comunicare i tuoi programmi anche attraverso Internet allora è meglio che usi i sockets e che al momento opportuno ti studi le estensioni aggiunte da Microsoft nei Windows Sockets 2 per lavorare con protolli diversi.

EDIT: io una volta ho realizzato un programma per chattare su reti LAN che usava le mailslot; se vuoi ti passo i sorgenti (è fatto in Visual C++ 6 con MFC).
comunque ricordo che su alcune reti il programma aveva un problema che ritengo fosse dovuto a qualche malfunzionamento delle mailslots contro i quali ti devo avvisare: a volte (non so quando e non so perché) le mailslot riceventi ricevono gli stessi messaggi due o tre volte, sono abbastanza sicuro che non dipendesse dal mio programma (ho controllato molto approfonditamente con l'aiuto del debugger); mi era venuto in mente di risolvere la questione usando dei transaction IDs nei miei messaggi (il programma ricevente doveva ignorare messaggi con TrID uguale a quello di un messaggio precedente), ma alla fine non l'ho più fatto per pigrizia
attualmente il mio programma funziona alla perfezione tranne che su alcune reti i messaggi di chat arrivano 2 o raramente 3 volte

Penso di rimanere con le WinSocks, perchè in un futuro penso di farlo comunicare attraverso internet

[-fidel-]

Ho ritrovato i link nella cronologia per fortuna...

A questo indirizzo puoi trovare una breve ma efficace guida sulla programmazione con winsock (si riferisce alla 1.1 ma per cominciare va benissimo, nulla di diverso dalla 2.0), presenta degli esempi di codice carini e commentati, ed è in italiano. La guida non si sofferma su problematiche pù avanzate come socket bloccanti/non bloccanti, broadcast/multicast ecc., ma appunto va bene per cominciare e fare subito qualche programma interessante. La guida è in italiano.

A quest'altro indirizzo trovi invece una guida un po' più approfondita della precedente, ma in inglese. Ah, ho letto velocemente la prima metà e ti consiglio di saltare la parte sulla configurazione del compilatore, è inutile se usi un compilatore Microsoft (VisualStudio - è tutto già configurato) ma anche in altri IDE (tipo Borland) di solito è già tutto a posto.

Un'ultima cosa: nella prima guida, ho dato un'occhiata al programma di esempio "bannerscan.c" in cui prova ad usare un socket non bloccante. Puoi leggerlo se vuoi, ma non prenderlo ad esempio Il modello non bloccante è più complesso di quello brevemente presentato in quell'esempio: lì praticamente, invece di aspettare la risposta del server per un tempo illimitato (modello bloccante) attende la risposta per un tempo prefissato, e se non c'è risposta passa al server successivo (!!). Questo è un comportamento assolutamente da evitare, perchè poco efficiente e porta quasi sempre a perdita di informazioni in una rete non LAN (ma anche in LAN molot "cariche"). Il modello non bloccante è invece "asincorno", e permette di ricontattare il server che in un primo momento non aveva risposto quando lo stesso server comunica che vuole mandare i dati richiesti. Per il resto tutto ok (ma del resto per cominciare il modello non bloccante lascialo perdere).

Ciao

[-fidel-]

Originariamente inviato da 71104

ah be', se lavori su una rete LAN allora puoi usare le named pipes oppure le mailslot che sono secondo me più semplici dei sockets; --cut--

Il meccanismo mailslot è molto semplice ed efficace se si lavora in rete locale (se non erro infatti non è possibile usare il meccanismo mailslot tra pc che risiedono in ip-range differenti), offre il meccanismo broadcast in modo trasparente, ma presenta una grande pecca.
Per comunicare, il meccanismo mailslot utilizza messaggi datagram (UDP) che non garantiscono alcun controllo sull'effettiva ricezione del messaggio. Se da un lato sono asincroni, e quindi evitano al programmatore i vari controlli sull'invio dei messaggi, dall'altro non puoi sapere se il messaggio inviato è stato effettivamente ricevuto oppure no. Quando si lavora con una mole di dati più consistente, diventa davvero inopportuno rischiare che il dato non arrivi a destinazione. Un'altra pecca è che i mailslot non sono portabili (sono supportati solo da sistemi Windows) a differenza dei sockets.

[71104]

Originariamente inviato da -fidel-

Il meccanismo mailslot è molto semplice ed efficace se si lavora in rete locale (se non erro infatti non è possibile usare il meccanismo mailslot tra pc che risiedono in ip-range differenti), offre il meccanismo broadcast in modo trasparente, ma presenta una grande pecca.
Per comunicare, il meccanismo mailslot utilizza messaggi datagram (UDP) che non garantiscono alcun controllo sull'effettiva ricezione del messaggio. Se da un lato sono asincroni, e quindi evitano al programmatore i vari controlli sull'invio dei messaggi, dall'altro non puoi sapere se il messaggio inviato è stato effettivamente ricevuto oppure no. Quando si lavora con una mole di dati più consistente, diventa davvero inopportuno rischiare che il dato non arrivi a destinazione. Un'altra pecca è che i mailslot non sono portabili (sono supportati solo da sistemi Windows) a differenza dei sockets.

be', anche per quelli c'è qualche differenza, bisogna stare attenti ai valori di ritorno, perciò alla fine qualche #ifdef a sporcare il codice ci va lo stesso.
per quanto riguarda le mailslot è vero che sono basate su un protocollo inaffidabile ma non concordo con il discorso sul lavorare con una grande mole di dati. una volta che il programmatore è "aware" del fatto che il protocollo sottostante è inaffidabile, il meccanismo di per se' rimane comunque più semplice da gestire rispetto a qualsiasi altro meccanismo sincrono: il fatto che io debba inviare dati da molti punti del codice non significa che per ciascuno di quei punti io debba fare altrettanti controlli circa l'arrivo o meno del messaggio; il controllo lo faccio una volta sola per tutte in una funzione apposita, e solo se serve perché in realtà considerando che il programmatore è cosciente di basarsi su un protocollo inaffidabile, progetterà la sua architettura di conseguenza, cioè senza mai fare in modo che tra una ricezione e l'altra i dati assumano uno stato incosistente. ovviamente il programmatore deve sempre valutare se nel suo caso sia realmente opportuno basarsi su un protocollo inaffidabile.
e poi via, se la rete è in buone condizioni fisiche quante volte le mailslot falliranno? anzi, a me pare che spesso funzionino bene il doppio o il triplo di come dovrebbero...

[-fidel-]

Originariamente inviato da 71104

per quanto riguarda le mailslot è vero che sono basate su un protocollo inaffidabile ma non concordo con il discorso sul lavorare con una grande mole di dati. una volta che il programmatore è "aware" del fatto che il protocollo sottostante è inaffidabile, il meccanismo di per se' rimane comunque più semplice da gestire rispetto a qualsiasi altro meccanismo sincrono: il fatto che io debba inviare dati da molti punti del codice non significa che per ciascuno di quei punti io debba fare altrettanti controlli circa l'arrivo o meno del messaggio; il controllo lo faccio una volta sola per tutte in una funzione apposita, e solo se serve perché in realtà considerando che il programmatore è cosciente di basarsi su un protocollo inaffidabile, progetterà la sua architettura di conseguenza, cioè senza mai fare in modo che tra una ricezione e l'altra i dati assumano uno stato incosistente. ovviamente il programmatore deve sempre valutare se nel suo caso sia realmente opportuno basarsi su un protocollo inaffidabile.
e poi via, se la rete è in buone condizioni fisiche quante volte le mailslot falliranno? anzi, a me pare che spesso funzionino bene il doppio o il triplo di come dovrebbero...

Sicuramente usare i mailslots è molto più semplice che usare i socket, per quanto le sue potenzialità siano limitate.
Comunque non ho capito una cosa del tuo ragionamento. Giacchè i mailslots usano un protocollo di trasporto inaffidabile, si pone il seguente problema:

1) un mailslot client invia un messaggio ad un mailslot server (magari in broadcast)
2) i mailslot server, controllando la coda messaggi, NON possono sapere se qualche messaggio è stato inviato (se trovano la coda vuota).

Tu mi dici che il programmatore, sapendo questo, organizza l'architettura di invio/ricezione in modo più intelligente. Ok, mi viene in mente ad esempio di fare una sorta di handshaking tra mailslot client e server per minimizzare il rischio di perdita messaggi. In questo caso però il numero di messaggi da scambiare tra client e server per singola transazione aumenta, peggiorando le prestazioni.

Il discorso nasce dal fatto che dici

"il fatto che io debba inviare dati da molti punti del codice non significa che per ciascuno di quei punti io debba fare altrettanti controlli circa l'arrivo o meno del messaggio; il controllo lo faccio una volta sola per tutte in una funzione apposita"

Come fai a controllare se il messaggio è arrivato? Devi implementare comunque un'architettura più sicura credo (tipo handshake).

EDIT: dimenticavo, i socket non sono necessariamente sincroni ok quelli asincroni sono più diffci da implementare, ma offrono grandi potenzialità e prestazioni. Questo a prescindere dai mailslot: mi sembra giusto, se devo implementare un semplice programma di IPC in LAN, usare un meccanismo più semplice dei socket: inutile sparare al passerotto col bazooka

[17Qwerty71]

Codice PHP:

WSADATA data; // inizializzo la variabile che contiene le primitive di Winsock
          WORD Version;
          int err=0; // inizializzo una variabile per gestire gli errori
          Version=MAKEWORD(2,0); // creo la variabile p che contiene la versione della wsock32.dll
          err=WSAStartup(Version,&data); // inizializzo la wsock32.dll verificandone la mancanza di errori
          SOCKET sock=socket(PF_INET,SOCK_STREAM,0);
          sockaddr_in sock_addr;
          sock_addr.sin_family=PF_INET; // indico il protocollo utilizzato (TCP/IP)
          sock_addr.sin_port=htons(21); //indico la porta a cui connettere il socket
          sock_addr.sin_addr.S_un.S_un_b.s_b1=127; // indico l'indirizzo IP
          sock_addr.sin_addr.S_un.S_un_b.s_b2=0;
          sock_addr.sin_addr.S_un.S_un_b.s_b3=0;
          sock_addr.sin_addr.S_un.S_un_b.s_b4=1;
          err=connect(sock,(struct sockaddr*)&sock_addr,sizeof(struct sockaddr));
          closesocket(sock);
          WSACleanup(); 


Il compilatore non mi riconosce la struttura sockaddr_in (ho include winsock.h)

[Fenomeno85]

Originariamente inviato da 17Qwerty71

Codice PHP:

WSADATA data; // inizializzo la variabile che contiene le primitive di Winsock
          WORD Version;
          int err=0; // inizializzo una variabile per gestire gli errori
          Version=MAKEWORD(2,0); // creo la variabile p che contiene la versione della wsock32.dll
          err=WSAStartup(Version,&data); // inizializzo la wsock32.dll verificandone la mancanza di errori
          SOCKET sock=socket(PF_INET,SOCK_STREAM,0);
          sockaddr_in sock_addr;
          sock_addr.sin_family=PF_INET; // indico il protocollo utilizzato (TCP/IP)
          sock_addr.sin_port=htons(21); //indico la porta a cui connettere il socket
          sock_addr.sin_addr.S_un.S_un_b.s_b1=127; // indico l'indirizzo IP
          sock_addr.sin_addr.S_un.S_un_b.s_b2=0;
          sock_addr.sin_addr.S_un.S_un_b.s_b3=0;
          sock_addr.sin_addr.S_un.S_un_b.s_b4=1;
          err=connect(sock,(struct sockaddr*)&sock_addr,sizeof(struct sockaddr));
          closesocket(sock);
          WSACleanup(); 


Il compilatore non mi riconosce la struttura sockaddr_in (ho include winsock.h)

devi linkare wsdata.lib o qualcosa del genere

comunque l'ip non si mette in quel modo

~§~ Sempre E Solo Lei ~§~

[-fidel-]

@ 17Qwerty71

Sì, devi indicare al compilatore che vuoi usare la libreria winsock2.dll.
Per farlo, ad esempio con visual studio, basta andare nelle opzione del progetto e, nella sezione (se non sbaglio) link (dai un'occhiata...), devi dire di includere lo stub 'winsock2.lib'. Lo stub .lib è uno speciale file include che informa il compilatore di linkare vs winsock2.dll

[dnarod]

e io che ho letto la guida e non ho idea di che farci con sti socket?? sono stupido? cioe, vorrei fare qualcosa di semplice per vedere se ho capito, ma non so nemmeno da dove partire...mi fa piacere che mi venga spiegato come si programmano i socket, ma alla fine di quella guida minuscola e e sicuramente non esaustiva c e una perla: "ora che sappiamo programmare i socket, possiamo fare fakemailers, trojan, eccetera"...sono sempre piu convinto di non avere alcuna dote naturale per la programmazione, perche io dopo aver letto quella guida, ne so sui socket quanto ne sapevo prima, cioe nulla; non so perche funzionano, non so cosa sono, non so come utilizzarli...so solo a grandi linee cosa fanno e come si devono utilizzare...possibile che ci esistano cervelloni che dopo aver letto una guida simile, a digiuno completo di socket, possano scrivere un programma qualsiasi che compila ed esegue qualcosa? non so tipo far venire fuori un messaggio "ciao!" in un computer in lan o sul proprio schermo? bah, ho sbagliato universita, me ne convinco sempre di piu ormai

[-fidel-]

Originariamente inviato da dnarod

e io che ho letto la guida e non ho idea di che farci con sti socket?? sono stupido? cioe, vorrei fare qualcosa di semplice per vedere se ho capito, ma non so nemmeno da dove partire...mi fa piacere che mi venga spiegato come si programmano i socket, ma alla fine di quella guida minuscola e e sicuramente non esaustiva c e una perla: "ora che sappiamo programmare i socket, possiamo fare fakemailers, trojan, eccetera"...sono sempre piu convinto di non avere alcuna dote naturale per la programmazione, perche io dopo aver letto quella guida, ne so sui socket quanto ne sapevo prima, cioe nulla; non so perche funzionano, non so cosa sono, non so come utilizzarli...so solo a grandi linee cosa fanno e come si devono utilizzare...possibile che ci esistano cervelloni che dopo aver letto una guida simile, a digiuno completo di socket, possano scrivere un programma qualsiasi che compila ed esegue qualcosa? non so tipo far venire fuori un messaggio "ciao!" in un computer in lan o sul proprio schermo? bah, ho sbagliato universita, me ne convinco sempre di piu ormai

Beh la prima guida che ho postato non è definibile come guida esaustiva... Magari la seconda è più completa (ma in inglese).
Cmq per programmare i socket ci vuole come prerequisito una sufficiente conoscenza della programmazione C.
Cos'è che non ti è chiaro?

[dnarod]

mi sono espresso malissimo perche ero amareggiato...il mio problema non è tanto il non avere capito un h, che è risolvibile...il mio problema è che non ho in alcun modo l acume per articolare un ragionamento su quello che ho letto...non ho assolutamente idea di come produrre qualcosa che funzioni (anche qualcosa di basilare, come un esempio di stampa di "ciao"), mentre da quello che mi sembra di capire, dovrei eccome...la base in c ce l ho, altrimenti non avrei nemmeno guardato il 3d (certo in java me la cavo di piu, ma non mi spaventa guardare 2 righe di c)

ad esempio: i due stralci server.c e client.c che ci sono in quella guida...che fanno? ho provato a pastarli in codeblocks e ed eseguirli ma non succede nulla...la cosa piu deprimente è che parlo come un niubbo totale ("ho provato ad eseguirli ma non succede nulla", odioso...) quando non lo sono, o non dovrei esserlo giacche sono ormai 3 anni che me la sbuccio con la programmazione all uni...a volte ci provo a pensare di non essere inutile, ma non c e verso, non c e una sola cosa che padroneggi bene, non mi stupirei di sbagliare un algoritmo elementare sugli array a questo punto...