[successivo] [precedente] [inizio] [fine] [indice generale] [violazione GPL] [translators] [docinfo] [indice analitico] [volume] [parte]


Capitolo 125.   Unix client-server program interface

UCSPI,(1) ovvero Unix client-server program interface, è un'interfaccia a riga di comando, che consente la comunicazione attraverso i socket a programmi che sono sprovvisti di questa funzionalità. In altri termini, consente di realizzare programmi che si avvalgono di questa interfaccia a riga di comando, senza bisogno di approfondire il problema della comunicazione con i socket.

125.1   Caratteristiche dell'interfaccia UCSPI

Per la realizzazione di un'interfaccia UCSPI serve una coppia di programmi: uno per il servente UCSPI e l'altro per il cliente. Il primo dei due è il programma che si mette in ascolto, in attesa di chiamate, l'altro è il programma chiamante. Entrambi questi programmi hanno una sintassi uniforme per la riga di comando:

nome_eseguibile [opzioni] indirizzo applicazione [argomenti_applicazione]

L'indirizzo è ciò che serve a raggiungere il socket del servente; per esempio potrebbe essere il nome di un file socket, oppure un indirizzo IP completo di porta.

Pertanto, l'indirizzo indicato in fase di avvio del servente serve a creare il socket, mentre quello che riguarda il cliente, serve a raggiungere il servente.

Questo servente o cliente UCSPI, quando una connessione si instaura, avvia un altro programma, ovvero l'applicazione, come indicato alla fine della riga di comando (assieme alle opzioni e agli altri argomenti che possano essere necessari all'applicazione stessa); il programma troverà alcune variabili di ambiente particolari che gli consentono di avere le informazioni necessarie riferite alla connessione. La comunicazione tra l'interfaccia UCSPI e l'applicazione avviene attraverso alcuni descrittori di file particolari.

Le opzioni standard che deve avere un'interfaccia UCSPI sono quelle seguenti, a cui se ne possono aggiungere altre.

Opzione Descrizione

-v

Mostra informazioni dettagliate.

-Q

Mostra informazioni solo sugli errori.

-q

Non emette alcuna informazione.

Le variabili di ambiente che vengono passate all'applicazione sono descritte nell'elenco seguente.

Variabile Descrizione

PROTO

Contiene il nome del protocollo utilizzato.

protocolloLOCAL*

Si tratta di una serie di variabili che iniziano per il nome del protocollo, continuano con la stringa LOCAL e terminano in vario modo, descrivono le caratteristiche specifiche del protocollo dal lato locale.

protocolloREMOTE*

Si tratta di una serie di variabili che iniziano per il nome del protocollo, continuano con la stringa REMOTE e terminano in vario modo, descrivono le caratteristiche specifiche del protocollo dal lato remoto.

Come accennato, la comunicazione tra l'interfaccia e l'applicazione avviene attraverso dei descrittori standard. Nel caso del servente, l'applicazione riceve dati leggendo lo standard input, mentre trasmette emettendo dati attraverso lo standard output.

Figura 125.1. Comunicazione tra il servente e l'applicazione.

zone

La comunicazione tra applicazione e cliente UCSPI è più difficile, perché è necessario lasciare liberi i descrittori dei flussi standard comuni (standard input, standard output e standard error), a disposizione dell'applicazione, per i propri fini. Pertanto, si usano i descrittori sei e sette, rispettivamente per la lettura e la scrittura.

Figura 125.2. Comunicazione tra il cliente e l'applicazione.

zone

A titolo di esempio, viene mostrato qualcosa di molto semplice: da una parte, un servente che, a ogni connessione, trasmette il contenuto del file /etc/passwd; dall'altra, un cliente che scorre questo risultato sullo schermo. Per cominciare, il servente viene definito in modo molto semplice:

servente indirizzo cat /etc/passwd[Invio]

Infatti, cat emette attraverso il suo standard output il contenuto del file /etc/passwd, che viene prelevato dal programma che costituisce l'interfaccia UCSPI, mentre lo standard input che conterrebbe il flusso di dati in ingresso dalla connessione, viene ignorato da cat.

La predisposizione dal lato cliente diventa invece un po' più difficile: serve almeno uno script:


#!/bin/bash
cat <&6- | less

In questo modo, si usa ancora cat, che attraverso lo standard input riceve invece quanto proveniente dal descrittore sei; quindi, quanto emesso da cat viene controllato da less (il descrittore sette non viene usato e questo significa che nulla viene inviato all'applicazione remota). Supponendo che lo script si chiami visualizza e sia collocato nella directory corrente:

cliente indirizzo ./visualizza[Invio]

Ciò dovrebbe essere sufficiente per poter visualizzare a ogni collegamento il contenuto del file /etc/passwd dell'elaboratore in cui si trova il servente.

125.2   UCSPI-unix

UCSPI-unix (2) è un pacchetto che realizza l'interfaccia UCSPI per le comunicazioni attraverso socket di dominio Unix. Si compone principalmente di due programmi, la cui sintassi specifica si descrive nel modo seguente:

unixserver [opzioni] file_socket applicazione [argomenti_applicazione]

unixclient [opzioni] file_socket applicazione [argomenti_applicazione]

Come si può intendere, unixserver apre un socket di dominio Unix (un file) e attende una connessione, mentre unixclient contatta la controparte attraverso l'indicazione dello stesso file.

La comunicazione con l'applicazione rispettiva avviene secondo le modalità standard delle interfacce UCSPI e le opzioni sono quelle standard, con l'aggiunta di altre specifiche per il tipo di socket (si consulti eventualmente unixserver(1)).

Volendo adattare l'esempio già mostrato in forma generalizzata a questo tipo di interfaccia, i comandi potrebbero essere quelli seguenti. Dal lato del servente:

unixserver /tmp/socket-prova cat /etc/passwd[Invio]

Dal lato del cliente serve uno script e il comando che avvia lo script:


#!/bin/bash
# ./visualizza
cat <&6- | less

unixclient /tmp/socket-prova ./visualizza[Invio]

Naturalmente, la scelta del file /tmp/socket-prova è arbitraria e dipende da come si avvia il servente.

Utilizzando uno script differente, è possibile controllare lo stato delle variabili di ambiente:


#!/bin/bash
set

Avviando unixclient con questo script, si possono notare, tra le altre, le variabili seguenti, che riguardano precisamente UCSPI-unix:

PROTO=UNIX
UNIXLOCALGID=1001
UNIXLOCALPATH=/tmp/socket-prova
UNIXLOCALPID=2145
UNIXLOCALUID=1001
UNIXREMOTEEGID=1001
UNIXREMOTEEUID=1001
UNIXREMOTEPID=2112

Le informazioni che derivano da queste variabili dovrebbero essere comprensibili già dal nome di queste, comunque vengono descritte brevemente nell'elenco seguente.

Variabile Descrizione

PROTO

Contiene la stringa UNIX a indicare che si tratta di socket di dominio Unix.

UNIXLOCALUID

UNIXLOCALGID

Si tratta rispettivamente del numero UID e GID del processo avviato localmente.

UNIXLOCALPID

Si tratta nel numero abbinato al processo locale.

UNIXLOCALPATH

Si tratta nel file socket a cui si fa riferimento per la connessione (lo stesso nome da entrambi i lati).

UNIXREMOTEEUID

UNIXREMOTEEGID

Si tratta rispettivamente del numero UID e GID del processo avviato dall'altra parte.

UNIXREMOTEPID

Si tratta nel numero abbinato al processo remoto.

125.3   UCSPI-tcp

UCSPI-tcp (3) è un pacchetto che realizza l'interfaccia UCSPI per le comunicazioni attraverso socket di dominio Internet, precisamente il protocollo TCP. Si compone principalmente di due programmi, la cui sintassi specifica si descrive nel modo seguente:

tcpserver [opzioni] host porta applicazione [argomenti_applicazione]

tcpclient [opzioni] host porta applicazione [argomenti_applicazione]

Anche in questo caso, tcpserver è il programma che si mette in ascolto (aprendo un socket di dominio Internet, con il protocollo TCP), mentre tcpclient contatta la controparte. Dal momento che si utilizza il protocollo TCP, il riferimento usato per comunicare è formato dall'indirizzo IP e dalla porta TCP del servente.

La comunicazione con l'applicazione rispettiva avviene secondo le modalità standard delle interfacce UCSPI e le opzioni sono quelle standard, con l'aggiunta di altre specifiche per il tipo di socket (si consulti eventualmente tcpserver(1) e tcpclient(1)). In particolare, nel servente è possibile stabilire il numero massimo di connessioni in coda; inoltre, entrambe le parti possono fissare un tempo massimo di scadenza per i tentativi di connessione.

Volendo adattare l'esempio già mostrato in forma generalizzata a questo tipo di interfaccia, i comandi potrebbero essere quelli seguenti. Dal lato del servente:

tcpserver dinkel.brot.dg 1234 cat /etc/passwd[Invio]

Dal lato del cliente serve uno script e il comando che avvia lo script:


#!/bin/bash
# ./visualizza
cat <&6- | less

tcpclient dinkel.brot.dg 1234 ./visualizza[Invio]

Naturalmente, la scelta della porta 1 234 è arbitraria, salvo il fatto che deve essere una porta libera e non privilegiata, dal momento che il servente viene avviato da un utente comune.

La comunicazione può risultare un po' in ritardo rispetto alle aspettative, perché prima viene fatta una verifica dell'identità delle parti attraverso il protocollo IDENT.

Utilizzando uno script differente, è possibile controllare lo stato delle variabili di ambiente:


#!/bin/bash
set

Avviando tcpclient con questo script, si possono notare, tra le altre, le variabili seguenti, che riguardano precisamente UCSPI-tcp:

PROTO=TCP
TCPLOCALHOST=roggen.brot.dg
TCPLOCALIP=192.168.1.2
TCPLOCALPORT=32993
TCPREMOTEHOST=dinkel.brot.dg
TCPREMOTEINFO=
TCPREMOTEIP=192.168.1.1
TCPREMOTEPORT=1234

Le informazioni che derivano da queste variabili dovrebbero essere comprensibili già dal nome di queste, comunque vengono descritte brevemente nell'elenco seguente.

Variabile Descrizione

PROTO

Contiene la stringa TCP a indicare che si tratta di socket di dominio Internet con protocollo TCP.

TCPLOCALHOST

TCPLOCALIP

TCPLOCALPORT

Si tratta rispettivamente del nome, dell'indirizzo IP e della porta nell'ambito locale.

TCPREMOTELHOST

TCPREMOTEIP

TCPREMOTEPORT

Si tratta rispettivamente del nome, dell'indirizzo IP e della porta nell'elaboratore remoto.

TCPREMOTEINFO

Informazioni particolari sulla controparte remota, ammesso che siano disponibili.

È da tenere in considerazione il fatto che tcpserver può essere controllato per evitare gli accessi indesiderati. Per questo si deve usare l'opzione -x, abbinando un file costruito con tcprules, che fa parte dello stesso pacchetto UCSPI-tcp (si veda tcprules(1)).

Appunti di informatica libera 2003.01.01 --- Copyright © 2000-2003 Daniele Giacomini -- daniele @ swlibero.org

1) In lingua inglese, UCSPI si pronuncia praticamente come se venisse letto nella lingua italiana: «u-c-s-p-i».

2) UCSPI-unix   GNU GPL

3) UCSPI-tcp   software libero per il quale non è consentita la diffusione in forma binaria, salvo approvazione esplicita da parte dell'autore


Dovrebbe essere possibile fare riferimento a questa pagina anche con il nome unix_client_server_program_interface.html

[successivo] [precedente] [inizio] [fine] [indice generale] [violazione GPL] [translators] [docinfo] [indice analitico]