Il controllo Winsock ed il protocollo TCP (Prima parte)
Utilizzando il controllo Winsock è possibile mettere in comunicazione due computer
sfruttando il protocollo TCP o UDP.
Quale protocollo utilizzare? Citando Microsoft come fonte: "[...] Il protocollo TCP (Transfer Control Protocol) consente di
creare e mantenere una connessione con un computer remoto.
Utilizzando la connessione, entrambi i computer possono inviare e ricevere dati. [...]
Il protocollo TCP è un protocollo basato sulla connessione ed è analogo ad un telefono, in
quanto l'utente deve stabilire una connessione prima di poter procedere [...]
Il
protocollo UDP (User Datagram Protocol) è un protocollo senza connessione.
A differenza del TCP, non viene stabilita alcuna connessione tra i computer [...]
e la transazione tra due computer è analoga al passaggio di un messaggio che viene
inviato da un computer all'altro senza che venga stabilita una connessione esplicita tra i
due computer. La dimensione massima dei dati che è possibile inviare in ciascuna trasmissione
dipende della rete [...].
Le applicazioni UDP possono essere applicazioni client o server.[...]"
In particolare, prendendo TCP come protocollo di riferimento, nel momento in cui i due computer sono in comunicazione, essi ricoprono dei ruoli
ben definiti.
Il computer Server invia i dati a chi ne fa richiesta utilizzando la porta
specificata mentre il computer Client esegue tale richiesta.
L'operazione che avviene tra Client e Server è riassumibile in tre punti fondamentali:
1. il computer Server è in attesa di richieste di comunicazione sulla porta indicata;
2. il computer Client richiede al Server l'autorizzazione ad iniziare una comunicazione;
3. una volta accettata la richiesta del Client, il computer Server invia i dati;
4. terminato lo scambio di dati la comunicazione viene chiusa
5. il computer Server torna in uno stato di attesa di eventuali richieste di comunicazione sulla porta indicata;
Prima di tutto comunque è necessario conoscere se le impostazioni TCP/IP del proprio computer
sono corrette.
Questo viene fatto più che altro per una ragione di scrupolo e di curiosità in quanto settaggi errati
provocherebbero maggiori disagi rispetto alla semplice impossibilità di utilizzare il controllo
Winsock in un progetto Visual Basic.
Se comunque si vuole procedere al controllo, sarà necessario aprire il prompt di Dos.
Una volta visualizzato il tipico schermo nero, scrivere la seguente linea:
dove NomeComputer rappresenta il nome oppure l'indirizzo IP del proprio computer.
Impostazioni TCP/IP corrette generano una risposta da parte del DOS di questo tipo:
mentre una risposta nella quale compaia il messaggio "host di destinazione non raggiungibile"
e che avverta che dei pacchetti di dati inviati nessuno è tornato indietro ma sono andati
tutti persi, indica naturalmente un problema di settaggio.
E'inoltre possibile ricevere un messaggio del tipo:
indica invece che è stato indicato un nome oppure un indirizzo IP non corretto del computer sul
quale è stato eseguita la prova.
Nel caso in cui il nome del proprio computer o dell'indirizzo IP ci risulti del tutto sconosciuto,
si può aprire un nuovo progetto EXE Standard, inserire un controllo Winsock sulla form (operazioni
che verranno comunque analizzate in dettaglio poco più avanti) ed aggiungere nel modulo di codice
di Form1 il seguente segmento di codice:
Private Sub Form_Load()
MsgBox Winsock1.LocalHostName
End Sub
|
Avviando l'applicazione si riceverà una finestra di messaggio recante il nome del proprio
computer.
La stessa cosa può essere fatta nel caso si voglia sapere l'identificativo IP:
Private Sub Form_Load()
MsgBox Winsock1.LocalIP
End Sub
|
Generalmente la cosa migliore è utilizzare il nome del computer più che l'indirizzo IP a meno
che non sia decisamente certi che questo non cambierà mai (come nel caso dell'applicazione
che andremo a sviluppare tra poco che, operando in locale, non richiede l'assegnazione di
un indirizzo IP differente da quello indicato dalla finestra di messaggio aperta poco fa).
Prima di cominciare a dare un primo sguardo ad un progetto di esempio, sarà necessario premettere
che le applicazioni distribuite dovranno in ogni caso fare riferimento al file MSWINSCK.OCX quindi
si dovrà provvedere a fornirlo con l'applicazione se si vuole essere sicuri che tutti ne possano
fare uso.
Un'ultima premessa: come si è visto dalla prova che abbiamo fatto appena sopra, non è assolutamente
necessaria la presenza di due computer fisici differenti.
Client e Server possono infatti essere
il medesimo computer e dunque coesistere in esso.
Dal prompt di DOS infatti non abbiamo fatto altro che inviarci dei pacchetti di dati e vedere se ed in quanto tempo ci sarebbero tornati indietro.
La figura sottostante dovrebbe chiarire meglio il concetto.
E' importante anche avere un quadro generale di quali operazioni l'oggetto possa compiere per noi.
Per questo motivo riassumiamo in tre tabelle le proprietà, i metodi e gli eventi che competono
a Winsock e che permettono di essere manipolato in modo agevole.
Non è il caso di preoccuparsi troppo se non si riesce a comprendere in modo chiaro l'utilità di
alcune caratteristiche di Winsock: andando avanti con lo sviluppo dell'applicazione che tra poco
inizieremo verranno utilizzate gran parte delle funzioni di cui il controllo dispone.
Questa è la tabella delle proprietà:
| Proprietà |
Descrizione
| Tipo di dato
|
| BytesReceived |
Corrisponde al numero di bytes scambiati
nell'operazione di comunicazione Client/Server. Rappresenta dunque le dimensioni dei pacchetti
di dati scambiati. Tale proprietà è associata al metodo GetData;
|
Long |
| LocalHostName |
Corrisponde al nome del computer sul
quale opera l'applicazione contenente il controllo Winsock;
|
String |
| LocalIP |
Corrisponde all'indirizzo del computer
sul quale opera l'applicazione contenente il controllo Winsock;
|
String |
| LocalPort |
E' il numero che identifica la porta
attraverso la quale verrà effettuata la comunicazione Client/Server. E' una proprietà di lettura
e scrittura anche in fase di esecuzione. In particolare:
Per il client, questa proprietà definisce la porta locale dalla quale vengono inviati i dati. Se l'applicazione non richiede una determinata porta, specificare la porta 0. Il controllo effettuerà la selezione casuale di una porta. Dopo aver stabilito la connessione, la porta locale verrà utilizzata per la connessione TCP.
Per il server, questa proprietà definisce la porta locale di attesa. Se viene specificata la porta 0, verrà utilizzata una porta casuale. Dopo aver richiamato il metodo Listen, la proprietà conterrà la porta selezionata;
|
Long |
| Protocol |
E' il tipo di protocollo che verrà utilizzato. La
scelta è tra TCP ed UDP. Prima di reimpostare questa proprietà è necessario chiudere il controllo utilizzando il metodo Close.
Le impostazioni di Protocol possono essere:
sckTCPProtocol caratterizzato dalla costante 0 che indica l'utilizo (predefinito) del protocollo TCP;
sckUDPProtocol caratterizzato dalla costante 1 che indica l'utilizo del protocollo UDP;
|
val/cost |
| RemoteHost |
E' nome del computer al quale ci si connette
per la richiesta di scambio dati;
|
String |
| RemoteHostIP |
E' l'indirizzo IP del computer al quale ci si connette
per la richiesta di scambio dati;
|
String |
| RemotePort |
Rappresenta la porta alla quale connettersi
per richiedere i dati. Quando viene impostata la proprietà Protocol, la proprietà RemotePort viene automaticamente impostata sulla porta predefinita appropriata di ciascun protocollo,
ossia:
porta 80 ->HTTP, utilizzata comunemente per le connessioni al World Wide Web;
porta 21 ->FTP
|
Long |
| SocketHandle |
E' un valore corrispondente all'handle di socket utilizzato dal controllo
per comunicare con il livello Winsock. E' una proprietà di sola lettura
e non disponibile in fase di progettazione. Tale proprietà sarà utilizzata
per essere passata alle API Winsock.
|
Long |
| State |
Restituisce lo stato del controllo Winsock nel momento in cui ne è richiesta la verifica.
I tipi di stato sono:
sckClosed corrispondente al valore 0. E' l'impostazione predefinita che corrisponde
allo stato 'chiuso' del controllo;
sckOpen corrispondente al valore 1 ed indica lo stato 'aperto' del controllo;
sckListening corrispondente al valore 2 ed indica lo stato 'in attesa di comunicazione' del controllo;
sckConnectionPending corrispondente al valore 3 ed indica lo stato 'comunicazione in corso' del controllo;
sckResolvingHost corrispondente al valore 4 ed indica lo stato 'risoluzione dell'host in corso' del controllo;
sckHostResolved corrispondente al valore 5 ed indica lo stato 'host risolto' del controllo;
sckConnecting corrispondente al valore 6 ed indica lo stato 'aperto' del controllo;
sckConnected corrispondente al valore 7 ed indica lo stato 'connesso' del controllo;
sckClosing corrispondente al valore 8 ed indica che il client sta chiudendo la comunicazione;
sckError corrispondente al valore 9 ed indica un errore in un'operazione eseguita da Winsock;
| Long |
La tabella dei metodi invece è la seguente:
| Metodo |
Descrizione
|
| BytesReceived |
Consente di accettare una richiesta
di comunicazione da parte del client. Generalmente il metodo Accept viene utilizzato nell'evento ConnectionRequest
ed in una nuova istanza del controllo Winsock anziché nel controllo in attesa;
|
| Bind |
Specifica la porta locale e l'IP locale da utilizzare per le connessioni TCP.
La sintassi è la seguente:
Winsock.Bind PortaLocale, IPLocale
dove PortaLocale è la porta utilizzata per effettuare la connessione e IPLocale è l'indirizzo IP locale utilizzato per effettuare la connessione;
|
| Close |
Chiude la comunicazione TCP o una socket in attesa per entrambe le applicazioni client e server;
|
| Connect |
Invia una richiesta di connessione ad un computer remoto.
La sintassi è la seguente:
Winsock.Connect HostRemoto, PortaRemota
dove HostRemoto è il nome del computer server al quale ci si connette e PortaRemota è la porta
utilizzata;
|
GetData |
Recupera il blocco di dati corrente e lo memorizza in una variabile di tipo Variant.
La sintassi è la seguente:
oggetto.GetData dati, [tipo,] [lunMax]
dove dati memorizza i dati recuperati dopo l'esecuzione del metodo. Se i dati non sono sufficienti per il tipo di richiesta, la variabile verrà impostato su Empty.
tipo è invece il tipo di dati da recuperare. Il metodo GetData viene in genere utilizzato con
l'evento DataArrival contenente l'argomento totalBytes.
Se il valore di lunMax è minore del valore dell'argomento totalBytes,
verrà visualizzato il messaggio di avviso 10040 in cui viene comunicato
che i byte rimanenti andranno perduti.
Le possibili impostazioni di tipo sono le seguenti:
vbByte Byte
vbIntegerInteger
vbLong Long
vbSingle Single
vbDouble Double
vbCurrency Currency
vbDate Date
vbBoolean Boolean
vbError SCODE
vbString String
vbArray + vbByte Byte Array
lunMax specifica la dimensione desiderata della matrice Byte o
della stringa da ricevere. Se non viene specificata alcuna matrice Byte
o stringa in questo argomento, verranno recuperati tutti i dati disponibili.
Se viene specificato un tipo di dati diverso da una matrice Byte o una stringa,
l'argomento verrà ignorato.
|
| Listen |
Crea una socket e la imposta in modalità di attesa. Questo metodo può essere utilizzato solo per le connessioni TCP;
|
| PeekData |
A differenza di GetData, il metodo PeekData non rimuove i dati dalla coda di input. Questo metodo può essere utilizzato solo per le connessioni TCP.
Tale metodo ha una sintassi praticamente simile a quella di GetData ossia:
Winsock.PeekData dati, [tipo,] [lunMax]
|
| SendData |
Invia i dati al computer remoto.
La sintassi è del tipo:
Winsock.SendData dati
dove dati rappresenta il gruppo di dati da inviare. Per i dati binari, è necessario utilizzare una matrice Byte.
Quando viene passata una stringa UNICODE, la stringa viene convertita in stringa ANSI prima di essere inviata dalla rete;
|
Si è parlato in questa tabella di socket. Un socket, come già accennato poco fa, è un oggetto attraverso il quale un'applicazione
che ne fa uso in modo specifico invia o riceve dati attraverso la rete con altri socket che fanno
uso dell' IPS (Internet Protocol Suite).
I socket sono bidirezionali ossia consentono allo stesso momento un flusso di dati sia in
entrata che in uscita.
Esistono due tipi di socket:
Stream sockets che consentono un flusso di dati continuo ed illimitato con la
garanzia di evitare duplicazione di dati inviati.
Datagram sockets non garantiscono che l'ordine di ricezione dei dati sia lo stesso
di quello di invio col rischio di non poter evitare duplicazione di dati (cioè stessi pacchetti
di dati possono arrivare a destinazione più volte).
Questa è la tabella degli eventi:
| Evento |
Descrizione
|
| Close |
Viene generato quando il computer
remoto interrompe la connessione;
|
| Connect |
Viene generato nel momento in cui
la connessione è stata stabilita con successo;
|
| ConnectionRequest |
Viene generato nel momento in cui
un computer client invia una richiesta di connessione. Il server può quindi decidere se accettare
o meno la comunicazione. In caso di rifiuto, il client riceverà l'evento Close ;
|
| DataArrival |
Viene generato nel momento in cui
un computer client riceve dei dati.
L'evento viene generato nel caso in cui tutti i nuovi dati inviati col metodo GetData siano
recuperati con successo. Per evitare duplicazione di pacchetti di dati solamente i nuovi
dati saranno considerati.
La sintassi è la seguente:
Winsock.DataArrival (BytesTotali As Long)
dove BytesTotali rappresenta il numero di dati che possono essere recuperati;
|
| Error |
Viene generato nel caso in cui si
verifichi un errore qualsiasi nel procedimento di connessione, di invio, di richiesta o
di chiusura della connessione.
La sintassi è la seguente:
Winsock.Error(Numero As Integer, Descrizione As String, Scode As Long, Origine As String, HelpFile as String, HelpContext As Long, CancelDisplay As Boolean)
dove Numero indica il codice dell'errore, Descrizione la descrizione dell'errore,
Scode è un valore di tipo Long SCODE, Origine descrive l'origine dell'errore, HelpFile è
una stringa conente il nome del file della Guida in linea, HelpContext è il contesto della
Guida in linea e CancelDisplay indica l'annullamento della visualizzazione.
L'impostazione predefinita (CancelDisplay = False) permette la visualizzazione di una
finestra di messaggio di errore predefinita.
Di seguito sono elencati i codici degli errori:
sckOutOfMemory corrispondente al valore 7. Descrive un errore causato dall'esaurimento
della memoria;
sckInvalidPropertyValue corrisponde al valore 380 e descrive un valore della proprietà
non valido
sckGetNotSupported corrispondente al valore 394. Descrive un errore causato dall'impossibilità
di leggere la proprietà;
sckSetNotSupported corrispondente al valore 383. Descrive un errore causato dall'impostazione
di una proprietà che è di sola lettura;
sckBadState corrispondente al valore 40006. Protocollo o stato della connessione errato per la transazione o la richiesta;
sckInvalidArg corrispondente al valore 40014. L'argomento passato a una funzione è in un formato errato o non è compreso nell'intervallo specificato.
sckSuccess corrispondente al valore 40017. Connessione completata.
sckUnsupported corrispondente al valore 40018. Indica un valore di tipo Variant non
supportato
sckInvalidOp corrispondente al valore 40020. Indica un'operazione non valida
sckOutOfRange corrispondente al valore 40021. Indica un argomento non compreso nell'intervallo.
sckWrongProtocol corrispondente al valore 40026. Indica che è stato usato un
protocollo per cui non è consentita l'operazione che si è tentato di compiere.
sckOpCanceled corrispondente al valore 1004. L'operazione è stata annullata.
sckInvalidArgument corrispondente al valore 10014. Indica che il flag non è stato impostato.
sckWouldBlock corrispondente al valore 10035. Indica che non è possibile bloccare il socket sebbene
ne sia stato specificato il blocco.
sckInProgress corrispondente al valore 10036. Indica che è in corso un'operazione Winsock
di blocco.
sckAlreadyComplete corrispondente al valore 10037. Indica che l'operazione richiesta è già
stata eseguita.
sckNotSocked corrispondente al valore 10038. Indica che non si fa riferimento ad un socket.
sckMsgTooBig corrispondente al valore 10040. Indica un datagramma troppo grosso per
essere inserito nel buffer.
sckPortNotSupported corrispondente al valore 10043. Indica che la porta specificata
non può essere utilizzata per l'operazione indicata.
sckAddressInUse corrispondente al valore 10048. Indica un indirizzo già in uso.
sckAddressNotAvailable corrispondente al valore 10049. Indica che l'indirizzo indicato del
computer locale non è valido.
sckNetworkSubsystemFailed corrispondente al valore 10050. Indica un errore nel sottosistema di rete.
sckNetworkUnreachable corrispondente al valore 10051. Indica che l'host non è in grado di
raggiungere la rete.
sckNetReset corrispondente al valore 10052. Indica che la connessione è stata
interrotta quando è stato impostato SO_KEEPALIVE.
sckConnectAborted corrispondente al valore 10053. Indica una connessione
fallita a causa di un timeout (tempo massimo di attesa superato) o di un altro errore.
sckConnectionReset corrispondente al valore 10054. Indica che la connessione è stata
reinviata dal computer remoto.
sckNoBufferSpace corrispondente al valore 10055. Indica che lo spazio nel buffer è esaurito.
sckAlreadyConnected corrispondente al valore 10056. Indica che la connessione è già stata stabilita.
sckSocketShutdown corrispondente al valore 10058. Indica che la connessione è già stata chiusa.
sckTimedout corrispondente al valore 10068. Indica che la connessione è stata chiusa.
sckConnectionRefused corrispondente al valore 10061. Indica che la connessione è stata rifiutata dal computer server.
sckNotInitalized corrispondente al valore 10093. Indica che è necessario richiamare WinsockInit per primo.
sckHostNotFound corrispondente al valore 11001. Indica che è impossibile trovare l'host in modo definitivo.
sckInvalidArgument corrispondente al valore 11002. Indica che è impossibile trovare l'host.
sckNotRecoverableError corrispondente al valore 11003. Indica un errore non riconoscibile.
sckNoData corrispondente al valore 11004. Indica che non è possibile ricevere alcun tipo di dati del tipo richiesto (quando
si fa uso della specifica Winsock.GetData (tipo).
|
| SendComplete |
Viene generato quando tutti i dati
sono stati inviati con successo;
|
| SendProgress |
Viene generato quando il processo di
invio dei dati è ancora in corso;
|
Per cominciare aprire un nuovo progetto EXE Standard. Selezionare quindi la voce 'Componenti'
dal menu 'Progetto'.
Apparirà dunque la finestra denominata 'Componenti'. Nella lista che presenta, contrassegnare
col segno di spunta la casella relativa alla voce 'Microsoft Winsock Control x.0' dove la x rappresenta
la versione disponibile sul proprio computer.
Come si è già detto, e com'è possibile intuire
dal messaggio ricevuto dalla finestra 'Componenti', è necessaria la presenza sul proprio computer
del file MSWINSCK.OCX.
Nel caso in cui detto file non si trovi nella classica cartella
"C:\WINDOWS\SYSTEM", premere il pulsante 'Sfoglia' della finestra 'Componenti' per ricercare
la posizione effettiva nella quale è situato il file.
Dando l'OK alla finestra dovrebbe apparire tra i controlli disponibili sulla sinistra della
finestra di lavoro di Visual Basic, il pulsante recante la tipica icona di Winsock proprio
come mostrato dall'immagine che segue. Questo indica che il controllo è pronto ad essere utilizzatoo
e trascinato sul piano, senza però la possibilità di ridimensionarlo
a piacimento.
Per simulare ciò che abbiamo fatto dal Prompt di DOS, dobbiamo rendere il nostro computer
sia Client che Server, permettendogli di richiedere e scambiare dati con se stesso.
A tale scopo, possiamo pensare di rinominare Form1 come frmServer, cosa che ci ricorderà in maniera
semplice che l'interfaccia ed il codice sviluppati per quella form sono relative alla funzione
Server del computer.
Aggiungiamo quindi a frmServer alcuni controlli. Saranno sufficienti due controlli TextBox (le caselle
di testo) ed un CommandButton (il pulsante).
Siccome come abbiamo visto, il server deve stare sempre in ascolto di eventuali
richieste di comunicazione che possono pervenire da altri computer, istruiamo Winsock a compiere
tale operazione sulla porta 100 all'apertura
dell'applicazione ossia nell'evento Load di frmServer :
Private Sub Form_Load()
Winsock1.LocalPort = 100
Winsock1.Listen
End Sub
|
Notare che il valore assegnato a LocalPort può essere un qualsiasi intero. Il computer
client deve però essere a conoscenza della porta sulla quale il server è in attesa. In caso
contrario non ci sarà alcuna risposta ad eventuali richieste di connessione.
Nel caso dell'applicazione che stiamo sviluppando risulta particolarmente semplice mettere
d'accordo client e server sulla porta comune da utilizzare in quanto essi coesistono sullo
stesso computer.
Abbiamo visto l'evento Load di frmServer. Adesso addentriamoci negli eventi più propriamente
legati al controllo Winsock. Innanzitutto istruiamo l'applicazione nel caso in cui si verifichi
una richiesta di connessione da parte del client sulla porta comune (in questo caso la 100).
Sarà necessario chiudere un'eventuale precedente connessione del server prima di accettare la nuova richiesta
da parte del client. Per far ciò dobbiamo controllare la proprietà State di Winsock. Tra tutti gli
stati che Winsock può assumere scegliamo 'Chiuso' e facciamo un ragionamento del tipo 'se lo
stato di Winsock è 'chiuso' allora vuol dire che non è in comunicazione con nessun computer
client. In questo caso si può accettare una nuova richiesta. In caso contrario (comunicazione
pendente, aperta, invio dati...) lo stato di Winsock deve tornare 'chiuso'.
Traduciamo il tutto con questo blocco di codice:
Private Sub tcpServer_ConnectionRequest(ByVal requestID As Long)
If tcpServer.State <> sckClosed Then tcpServer.Close
|
Non chiudiamo la sottoprocedura in quanto dobbiamo aggiungere il codice che indichi a Winsock
di ricevere la richiesta nel caso in cui lo stato sia 'chiuso', cosa che faremo la prossima volta.
|
