Middlewares

Debug Teredo (netsh)

noreply@blogger.com (Ska) — Thu, 21 Feb 2008 13:00:00 +0000

In questo post vediamo come possiamo testare il funzionamento del Teredo client utilizzando la shell di windows netsh, con la quale è possibile gestire tutto il networking di Windows.
Per prima cosa è necessario controllare lo stato della lista dei cloud è vedere se in questa è presente la cloud Global_; questo è possibile tramite il comando:

netsh p2p pnrp cloud show list

Se la cloud Global_ non è presente bisognerà controllare lo stato di Teredo, in quanto la causa di tale mancanza probabilmente è da attribuire alla fatto che il server Teredo non è riuscito ad assegnare un indirizzo IPv6; quindi per controllare lo stato di Teredo:

netsh interface ipv6 show teredo in Xp
netsh interface teredo show state in Vista

Se lo stato è risulta probe, vuol dire che il client Teredo sta cercando di comunicare con il server Teredo per ottenere un indirizzo IPv6; se invece si riscontra lo stato di dormant o qualified allora il client sta funzionando correttamente; se è unreachable, bisognerà controllare che qualche firewall non blocchi la porta 3544; ed infine se si trova come stato "client is a managed network", probabilmente il client Teredo si trova all' interno di una rete aziendale gestita, e dovremo settare la modalità di funzionamento del client su "enterprise" con il seguente comando:

netsh interface ipv6 set teredo type=enterpriseclient in Xp
netsh interface teredo set state enterpriseclient in Vista

Se invece nella lista delle cloud, Global_ è presente, ma si trova nello stato virtual, vuol dire che ancora non è finito il processo di inizializzazione e si può provare a dare il comando:

netsh p2p pnrp cloud start Global_

Teredo

noreply@blogger.com (Ska) — Wed, 20 Feb 2008 09:58:00 +0000

Teredo è un protocollo di tunneling che consente di fornire una connessione su IPv6 a nodi che si trovano dietro dispositivi NAT non provvisti di IPv6, definendo un modo per incapsulare pacchetti IPv6 in pacchetti UDP IPv4, rendendo possibile l' attraversamento NAT e fornendo all'host un indirizzo globale dal quale chiunque in Internet può inviare /ricevere traffico.
Questo protocollo è alternativo a 6to4, il quale necessita di un indirizzo pubblico e della funzionalità di 6to4 routing implementata sul dispositivo.
L' infrastruttura Teredo è formata da i seguenti componenti:

Teredo Clients
Teredo Servers
Teredo Relays
Teredo Host-specific Relays

Principalmente un client Teredo comunica con un server Teredo allo scopo di ottenere in Internet un indirizzo IPv6, per poter comunicare con altri client Teredo o con altre macchine aventi indirizzo IPv6.
Il client Teredo è incluso in Windows XP SP2, Windows XP SP1 con l' Advanced Networking Pack for Windows XP, Windows Server 2003 con Service Pack 1, Windows Server 2003 Service Pack 2, Windows Vista, e Windows Server 2008.
Il relay Teredo ha invece la funzione di forwardare pacchetti tra client Teredo in Internet IPv4 e host IPv6-only.

P2P e PNRP su XP

noreply@blogger.com (Ska) — Sun, 07 Oct 2007 12:29:00 +0000

Il P2P networking stack non è installato di default su Windows XP ( diversamente da Vista ).
Per installarlo su Windows XP con service pack 2, bisogna seguire i passi elencati qui sotto:

Start > Pannello di controllo > Aggiungi/Rimuovi programmi
Installazione componenti di Windows
Spuntare servizi di rete e selezionare Dettagli
Spuntare la checkbox Peer-to-Peer e selezionare OK
Cliccare su Next e seguire le istruzioni sullo schermo

Oltre a questi passi, se si ha il service pack 1 anzichè il 2, allora bisognerà installare anche Windows Networking Pack per Windows XP.
Bisognerà inoltre aggiungere, tra le eccezioni del firewall, il PNRP.
Successivamente è necessario scaricare è installare l' aggiornamente WindowsXP-KB920342-x86-ITA, ( è molto importante controllare che la lingua dell' aggiornamento che si sta per scaricare sia uguale a quella del impostata nel sistema operativo ).
A questo punto, visto che Pnrp funziona con IPv6, si dovrà installare tale supporto; questo potrà essere fatto digitando da console "install ipv6" e battendo invio. Naturalmente bisognerà controllare che una volta installato, tale supporto, sia abilitato tra le proprietà della scheda di rete che dovrà usare il Pnrp.
Se si è dietro router, si dovranno forwardare le porte 3540 udp ( Teredo ) e la 3587 tcp ed dietro firewall comunque tali porte andranno aperte.

PNRP

noreply@blogger.com (Ska) — Mon, 01 Oct 2007 11:13:00 +0000

In ambiente peer-to-peer, la problematica principale è rappresentata dalla risoluzione dei nomi dei peer. Microsoft risolvere questo problema con il Peer Name Resolution Protocol (PNRP), sviluppato prima per Windows XP, e successivamente aggiornato in Windows Vista.
Come si può leggere dalla documentazione tecnica, PNRP funziona in modo totalmente diverso dagli altri sistemi di risoluzione dei nomi ed offre le seguenti proprietà:

Distribuito e senza server
Agevole pubblicazione del nome senza intervento di terzi ( al contratio di DNS )
Aggiornamento in tempo reale ( al contratio di DNS )
Nomi oltre l' identificazione della macchina ( si posso assegnare nomi a singoli servizi )
Pubblicazione protetta dei nomi ( è possibile usare una modalità sicura )

Pnrp si basa sui Clouds, cioè un raggruppamento di computer in grado di individuarsi reciprocamente. I Clouds offerti da PNRP sono due:

La cloud global: rappresenta tutti i computer sull' intera internet IPv6
La cloud local: ambito di indirizzi IPv6 locali

Il peer è identificato da un nome che rappresenta l' endpoint per la comunicazione; questo può essere indiferentemente un computer, un utente, un servizio o un qualsiasi altro oggetto.
I nomi possono essere registrati in maniera sicura o non sicura. Nel primo caso saranno protetti da certificato e firma digitale.
L' ID PNRP del peer ha una lunghezza di 256 bits:

128 bit che rappresentano l' ID P2P, un hash nome attribuito ad un endpoint che a sua volta è diviso in Authority.Classifier; nei nomi non sicuri, Authority è 0. Classifier identifica l' applicazione è può essere una stringa Unicode di lunghezza massima di 250 caratteri
Gli altri 128 bits sono un numero generato che identifica diverse instanze dello stesso ID P2P sullo stesso cloud

Per quanto riguarda la risoluzione dei nomi, questa si compone di due fasi:

Determinazione dell' endpoint (risoluzione dell' indirizzo ipv6 del peer che espone il servizio)
Risoluzione dell' ID PNRP

Durante la determinazione dell'endpoint, PNRP utilizza un processo iterativo per individuare il nodo che ha pubblicato l'ID PNRP. Nel processo, il nodo che sta eseguendo la risoluzione ha il compito di contattare in successione i nodi più vicini all'ID PNRP finale.

Per eseguire la risoluzione del nome in PNRP, il peer esamina le voci nella propria cache alla ricerca di un elemento che corrisponda all'ID PNRP finale. In caso di esito positivo, il peer invia un messaggio di richiesta PNRP al peer e attende la risposta. In caso negativo, se il peer trova però un ID PNRP che somiglia a quello richiesto, manda al richiedente come risposta l' IPv6 di tale peer, e quindi il richiedente interrogherà quest' ultimo peer. Se invece il peer interrogato non trova l' ID PNRP richiesto, ne uno somigliate, allora questo manderà un messaggio con la situazione accertata al richiedente che sceglierà il secondo ID PNRP più vicino.
Consideriamo il seguente scenario, e supponiamo che il peer A desidera determinare l'endpoint relativo all'ID PNRP di 800

Dato che 500 è numericamente più vicino a 800, il peer A invia un messaggio di richiesta PNRP al nodo che ha registrato l'ID PNRP di 500 (peer C)
Il peer C non ha voci relative all'ID PNRP di 800 o più vicine a 800, quindi risponde al peer A illustrando tale situazione.
Dato che 450 è il secondo numericamente più vicino a 800, il peer A invia un messaggio di richiesta PNRP al nodo che ha registrato l'ID PNRP di 450 (peer B)
che dispone nella cache di una voce relativa all'ID PNRP ID di 800 e quindi invia l'indirizzo IPv6 del peer E al peer A
Il peer A invia una richiesta PNRP al peer E
Il peer E risponde positivamente al peer A con la risoluzione del nome

Fonte microsoft technet

DHT, Distributed Hash Tables

noreply@blogger.com (Ska) — Wed, 20 Jun 2007 08:50:00 +0000

Nell' ambito dei sistemi distribuiti e decentralizzati, la tabella hash distribuita ha rappresentato una svolta.
Applicata in molti nuovi sistemi peer to peer (BitTorrent, Kademlia ...), sono stati sviluppati molti algoritmi basati su questa architettura, ed alcuni sono ancora in sviluppo come ad esempio Chord.
L' idea di questo tipo di algoritmi è di usare una funzione di hash per mappare la risorsa da cercare (un oggetto, un servizio o più semplicemente un file come nel caso delle reti peer to peer) con un identificativo unico, e nel distribuire il range dei possibili valori della funzione di hash tra tutti i nodi della rete.
In generale le DHT offrono due servizi:

Lookup(key)
Insert(key, value)

dove key identifica la risorsa e value l' indirizzo logico dell' host.

Vadiamo come funziona l' algoritmo Chord nella sua forma più semplice.
E' importante notare che i nodi e le key condividono lo stesso spazio degli identificatori, cioè l' hashing ottenuto con SHA-1, dal quale si possono ottenere 2^160 identificatori.

L' id (value) di un nodo è ottenuto dall' hash del suo indirizzo ip, mentre la key dall' hash del valore della chiave cercata.
I possibili identificatori vengono organizzati in cerchio, in ordine crescente
Una key K, viene assegnata al primo nodo il cui identificatore è uguale o maggiore di K
N viene indicato come nodo successore della key, successor(K)

Un possibile algoritmo di routing, molto semplice, si può realizzare facendo in modo che ogni nodo conosca esclusivamente il link verso il suo successore.

noreply@blogger.com (Ska) — Mon, 02 Oct 2006 11:49:00 +0000

In quest' articolo farò un esempio per spiegare come si utilizza e come funziona CORBA in pratica. L' esempio consiste di un semplice oggetto calcolatrice, che potrà essere invocato da un client remoto, il quale passerà due parametri al metodo somma che restituirà il risultato.
La prima cosa da fare è construire l' interfaccia in IDL :



 // matematica.idl

 module matematica{

   interface Calcolatrice{
     long somma(in long a, in long b);
   };

 };

Naturalmente somma sarà il metodo di calcolatrice che esporrà l' interfaccia.
matematica.idl andrà compilato con il seguente comando:


 idlj -full -oldImplBase matematica.idl

L'operazione di sopra causerà la creazione di una directory di nome "matematica" con all' interno i seguenti file:

_CalcolatriceImplBase.java ( Questa classe rappresenta lo Skeleton )
_CalcolatriceStub.java ( Lo Stub )
Calcolatrice.java ( Definisce l' interfacia dell' oggetto CORBA )
CalcolatriceOperations.java ( Definisce l' interfacia dell' oggetto CORBA )
CalcolatriceHelper.java ( Verrà spiegato più avanti )
CalcolatriceHolder.java ( Verrà spiegato più avanti )

Ora la prossima cosa da fare è "specializzare" lo skeleton, in quanto _CalcolatriceImplBase è una classe astratta. Quindi:



 // CalcolatriceImpl.java

 package matematica;

 import matematica.*;

 public class CalcolatriceImpl extends _CalcolatriceImplBase {

   public CalcolatriceImpl() {

     super();

   }

   public int somma(int a, int b){

     return a + b;

   }

}

Implementiamo ora la classe server:



// CalcolatriceServer.java

package server;

import matematica.*;
import java.io.*;

public class CalcolatriceServer{

  public static void main(String[] args){

    if(args.length != 1) {
      System.err.println("Manca l'argomento: path file ior\n");
      return;
    }

    try{

      // Inizializza l'ORB
      org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init(args, null);

      // Crea un oggetto Calcolatrice
      CalcolatriceImpl calc = new CalcolatriceImpl();

      // Stampa l'object reference in versione stringa
      System.out.println("Creata Calcolatrice:\n" +
                                     orb.object_to_string(calc));

      // Scrive l'object reference nel file
      PrintWriter out = new PrintWriter(new BufferedWriter(
                                        new FileWriter(args[0])));
      out.println(orb.object_to_string(calc));
      out.close();

      // Attende l' invocazione di un client
      java.lang.Object sync = new java.lang.Object();
      synchronized (sync) {
        sync.wait();
      }

    }catch (Exception e) {
      System.err.println("Server error: " + e);
      e.printStackTrace(System.out);
    }
  
  }

}

A questo punto è doverosa un precisazione.
In questo esempio si sta utilizzando come reference per l' oggetto un filesystem, perchè per il momento siamo interessati meccanismo di funzionamento base di CORBA. Quindi questo esempio funzionerà sicuramente eseguendo client e server sulla stessa macchina, ma affinchè funzioni anche su due macchine separate è necessario che entrambe abbiano un porzione di filesytem in comune, dove poter scrivere/leggere il file calc.ior, il nostro "object reference".
Fatta questa precisazione implementiamo il client:



  // CalcolatriceClient.java

  package client;

  import matematica.*;
  import java.io.*;

  public class CalcolatriceClient{

    public static void main(String args[]){

      if(args.length!=1){
        System.err.println("Manca argomento: path file ior");
        return;
      }

      try{

        // Crea e inizializza l' ORB
        org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init(args, null);

        // Legge dal file il reference all' oggetto
        // Si assume che il server lo abbia generato
        BufferedReader in = new BufferedReader(new FileReader(args[0]));
        String ior = in.readLine();
        in.close();

        // Ottiene dal reference un oggetto remoto ...
        org.omg.CORBA.Object obj = orb.string_to_object(ior);

        // ...e ne effettua il narrow a tipo Calcolatrice
        Calcolatrice calc = CalcolatriceHelper.narrow(obj);

        // Ottiene da input tastiera i 2 numeri da sommare
        BufferedReader inputUser = new BufferedReader(
                                   new InputStreamReader(System.in));
        String first, second;
        int a, b;

        // Leggo primo addendo
        System.out.println();
        System.out.println("A = ");
        first = inputUser.readLine();
        a = Integer.valueOf(first).intValue();

        // Leggo secondo addendo
        System.out.println();
        System.out.println("B = ");
        second = inputUser.readLine();
        b = Integer.valueOf(second).intValue();

        // Invoca il metodo remoto passandogli i parametri
        System.out.println();
        System.out.println("Il risultato è: ");
        System.out.println(calc.somma(a, b));

      }catch (Exception e){
        e.printStackTrace();
      }
  
    }

  }

noreply@blogger.com (Ska) — Sun, 01 Oct 2006 17:35:00 +0000

Diamo uno sguardo all' architettura corba.
Come si può vedere dalla figura il cuore dell' architettura è il canale di comunicazione ( ORB ).
Fornisce l' infrastruttura che permette agli oggetti di comunicare indipendentemente dal linguaggio e dalla piattaforma adottata. ORB nasconde al client tutti i dettagli sulla localizzazione degli oggetti sulla rete e sul loro linguaggio di implementazione; l' ORB individua l' oggetto sulla rete e effettua le necessarie traslazioni nel linguaggio di implementazione ( naturalmente per quei linguaggi per i quali è stato definito un mapping ). Praticamente l' ORB nasconde al client che l' oggetto che sta invocando si trova in remoto.
Il Client invoca i metodi del Servant che invece è l' implementazione dell' oggetto remoto; quest' invocazione avviene tramite l' entità logica ORB che fornisce i meccanismi per inviare le richieste da un client all' oggetto remoto. L' ORB è definito tramite un interfaccia astratta che nasconde completamente alle applicazioni i dettagli sull' implementazione: ORB Interface.
IDL Stub fa da collante tra client e ORB, occupandosi del "marshalling" dei dati, mentre dualmente, IDL Skeleton fa da collante tra servant e ORB e fa l' "unmarshalling dei dati".
Sono anche presenti DII, che consente ad un client di invocare un oggetto remoto senza conoscere la definizione della sua interfaccia e senza avere un legame con lo stub, e il DSI che consente a ORB di recapitare un request ad un oggetto che non ha uno skeleton statico.
Un altro componente molto importante nell' architettura ORB è l' Object Adapter, che assiste ORB nel recapitare le request a un oggetto e nelle operazioni di attivazione/disattivazione degli oggetti.

noreply@blogger.com (Ska) — Sun, 01 Oct 2006 16:39:00 +0000

CORBA ( Common Object Request Broker Architecture ) è un middleware, cioè uno strato di software posto tra la lo strato di rete del sistema operativo e quello applicativo; definisce un' infrastruttura standard per la comunicazione tra e con oggetti remoti distribuiti ovunque distribuiti, indipendentemente dal linguaggio usato per l' implementazione e dalla piattaforma di esecuzione.
Questo significa che gli oggetti possono essere scritti in un qualsiasi linguaggio per il quale è stato creato un mapping CORBA ( quasi tutti i linguaggi più conosciuti ).
Questi oggetti saranno in grado di comunicare tra loro grazie all' ORB ( Object Request Broker ), che è appunto il canale di comunicazione dell' ambiente distribuito.
Gli altri principi sui quali è basato corba sono:

Separazione tra l' interfaccia e l' implementazione
Trasparenza della localizzazione delle risorse
Ogni riferimento a un oggetto ha un tipo definito nella sua interfaccia