Differences between revisions 1 and 7 (spanning 6 versions)
⇤ ← Revision 1 as of 2009-04-09 11:37:42 →
Size: 910
Editor: anonymous
Comment:
← Revision 7 as of 2009-05-25 17:02:52 → ⇥
Size: 4747
Editor: lukisi
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
= Remotable Functions = = Chiamate a metodi remoti =
Line 3: Line 3:
Sono le funzioni (metodi) richiamabili attraverso il meccanismo RPC (vedi il [[../ModuloRPC|modulo RPC]]). Nel programma Netsukuku esistono delle funzioni (metodi) richiamabili da remoto attraverso il meccanismo RPC (vedi il [[../ModuloRPC|modulo RPC]]).
Line 5: Line 5:
Si può specificare quali metodi di una certa classe sono remotable. Si può specificare quali metodi di una certa classe sono ''remotable''.
Line 7: Line 7:
A partire da un certo oggetto (istanza di una classe) chiamato root_instance, che viene specificato al momento dell'avvio del MicroTCPServer o MicroUDPServer, tutti i suoi attributi si possono "accedere" da remoto. E per ogni attributo che contiene un oggetto, di nuovo tutti i suoi attributi si possono "accedere" da remoto. A partire da un certo oggetto (istanza di una classe) chiamato root_instance, che viene specificato al momento dell'avvio del {{{MicroTCPServer}}} e dei {{{MicroUDPServer}}} (un UDP per ogni scheda di rete), tutti i suoi attributi si possono "accedere" da remoto. E per ogni attributo che contiene un oggetto, di nuovo tutti i suoi attributi si possono "accedere" da remoto.
Line 11: Line 11:
Bisogna poi vedere quali di questi metodi si possono veramente richiamare. Questo si controlla appunto specificando quali metodi della classe sono remotable. Bisogna poi vedere quali di questi metodi si possono veramente richiamare. Questo si controlla appunto specificando quali metodi di una data classe sono remotable.
Line 13: Line 13:
== Elenco delle funzioni remotable == == Oggetto radice e suoi attributi ==
Line 15: Line 15:
=== Modulo Radar === La root_instance fornita dal demone di Netsukuku è l'unica istanza della [[../ClasseNtkNode|classe NtkNode]].
Line 17: Line 17:
 . radar.reply
 . radar.time_register
 . neigh.ip_change		 Tra i suoi attributi sono:
 . {{{self.radar = radar.Radar(...)}}}
 . {{{self.neighbour = self.radar.neigh}}}
 . {{{self.maproute = maproute.MapRoute(...)}}}
 . {{{self.etp = qspn.Etp(...)}}}
 . {{{self.p2p = p2p.P2PAll(...)}}}
 . {{{self.coordnode = coord.Coord(...)}}}
 . {{{self.hook = hook.Hook(...)}}}
 
In particolare l'attributo {{{p2p}}} è un oggetto {{{P2PAll}}}. Questo ha un numero dinamico di attributi interessanti, perché richiamando un suo attributo con nome {{{PID_}}}''{{{n}}}'' (dove ''{{{n}}}'' è un qualsiasi intero) si ottiene un oggetto della classe {{{P2P}}}.

I {{{TCPClient}}} sono memorizzati sull'attributo {{{ntkd}}} dell'oggetto {{{Neigh}}}.
<<BR>>
Gli oggetti {{{Neigh}}} si passano insieme agli eventi {{{NEIGH_NEW}}}, {{{NEIGH_REM_CHGED}}}, {{{NEIGH_DELETED}}} oppure si richiedono alla istanza locale di {{{Neighbour}}} con il metodo {{{neigh_list}}}.

Quindi sul codice si trovano pezzi simili a questo:
<<BR>>
{{{ neigh.ntkd.etp.etp_exec(...)}}}
<<BR>>
'''{{{neigh}}}''' è un oggetto {{{Neigh}}} ricevuto attraverso un evento. Attraverso l'attributo '''{{{ntkd}}}''' esegue una chiamata RPC. La root_instance (sull'host remoto) è l'oggetto {{{NtkNode}}}, il quale ha un attributo '''{{{etp}}}''' che è una istanza della classe {{{Etp}}}. La classe {{{Etp}}} ha la funzione remotable '''{{{etp_exec}}}'''. La chiamata quindi risulta corretta.

Altro esempio potrebbe essere:
<<BR>>
{{{ n.ntkd.p2p.PID_12.msg_send(...)}}}
<<BR>>
'''{{{n}}}''' è un oggetto {{{Neigh}}} richiesto alla istanza locale di {{{Neighbour}}}. Attraverso l'attributo '''{{{ntkd}}}''' esegue una chiamata RPC. La root_instance (sull'host remoto) è l'oggetto {{{NtkNode}}}, il quale ha un attributo '''{{{p2p}}}''' che è una istanza della classe {{{P2PAll}}}. La classe {{{P2PAll}}} ha un attributo (dinamico) '''{{{PID_12}}}''' che è una istanza della classe {{{P2P}}}. La classe {{{P2P}}} ha la funzione remotable '''{{{msg_send}}}'''. La chiamata quindi risulta corretta.

Invece il {{{BcastClient}}} viene istanziato e memorizzato sull'attributo {{{broadcast}}} dell'oggetto {{{Radar}}}.
<<BR>>
Oppure si può istanziare un {{{BcastClient}}} all'abbisogna.

Quindi sul codice si trovano pezzi simili a questo:
<<BR>>
{{{ self.broadcast.radar.reply(...)}}}
<<BR>>
'''{{{self.broadcast}}}''' è un oggetto {{{BcastClient}}} attraverso il quale si esegue una chiamata RPC ''in broadcast''. La root_instance (su tutti gli host Netsukuku della LAN) è l'oggetto {{{NtkNode}}}, il quale ha un attributo '''{{{radar}}}''' che è una istanza della classe {{{Radar}}}. La classe {{{Radar}}} ha la funzione remotable '''{{{reply}}}'''. La chiamata quindi risulta corretta.

== Parametri formali speciali ==

'''''TODO''': spiegazione del _rpc_caller''

== Elenco dei metodi remotable ==

=== Modulo radar ===

 . ~+{{{class Radar(object)}}}+~
  . {{{reply Riceve _rpc_caller}}}
  . {{{time_register Riceve _rpc_caller}}}

 . ~+{{{class Neighbour(object)}}}+~
  . {{{ip_change}}}

=== Modulo route ===

 . ~+{{{class MapRoute(Map)}}}+~
  . {{{free_nodes_nb}}}

=== Modulo qspn ===

 . ~+{{{class Etp}}}+~
  . {{{etp_exec}}}

=== Modulo hook ===

 . ~+{{{class Hook(object)}}}+~
  . {{{communicating_vessels}}}
  . {{{highest_free_nodes}}}

=== Modulo p2p ===

 . ~+{{{class P2P(RPCDispatcher)}}}+~
  . {{{partecipant_add}}}
  . {{{msg_send}}}

 . ~+{{{class P2PAll(object)}}}+~
  . {{{pid_getall}}}

=== Modulo coord ===

 . ~+{{{class MapCache(Map)}}}+~
  . {{{map_data_merge}}}

 . ~+{{{class Coord(P2P)}}}+~
  . {{{going_out}}}
  . {{{going_out_ok}}}
  . {{{going_in}}}

Chiamate a metodi remoti

Nel programma Netsukuku esistono delle funzioni (metodi) richiamabili da remoto attraverso il meccanismo RPC (vedi il modulo RPC).

Si può specificare quali metodi di una certa classe sono remotable.

A partire da un certo oggetto (istanza di una classe) chiamato root_instance, che viene specificato al momento dell'avvio del MicroTCPServer e dei MicroUDPServer (un UDP per ogni scheda di rete), tutti i suoi attributi si possono "accedere" da remoto. E per ogni attributo che contiene un oggetto, di nuovo tutti i suoi attributi si possono "accedere" da remoto.

Dicendo che "si può accedere" si intende che si possono richiamare i suoi metodi.

Bisogna poi vedere quali di questi metodi si possono veramente richiamare. Questo si controlla appunto specificando quali metodi di una data classe sono remotable.

Oggetto radice e suoi attributi

La root_instance fornita dal demone di Netsukuku è l'unica istanza della classe NtkNode.

Tra i suoi attributi sono:

  • self.radar = radar.Radar(...)

  • self.neighbour = self.radar.neigh

  • self.maproute = maproute.MapRoute(...)

  • self.etp = qspn.Etp(...)

  • self.p2p = p2p.P2PAll(...)

  • self.coordnode = coord.Coord(...)

  • self.hook = hook.Hook(...)

In particolare l'attributo p2p è un oggetto P2PAll. Questo ha un numero dinamico di attributi interessanti, perché richiamando un suo attributo con nome PID_n (dove n è un qualsiasi intero) si ottiene un oggetto della classe P2P.

I TCPClient sono memorizzati sull'attributo ntkd dell'oggetto Neigh.
Gli oggetti Neigh si passano insieme agli eventi NEIGH_NEW, NEIGH_REM_CHGED, NEIGH_DELETED oppure si richiedono alla istanza locale di Neighbour con il metodo neigh_list.

Quindi sul codice si trovano pezzi simili a questo:
    neigh.ntkd.etp.etp_exec(...)
neigh è un oggetto Neigh ricevuto attraverso un evento. Attraverso l'attributo ntkd esegue una chiamata RPC. La root_instance (sull'host remoto) è l'oggetto NtkNode, il quale ha un attributo etp che è una istanza della classe Etp. La classe Etp ha la funzione remotable etp_exec. La chiamata quindi risulta corretta.

Altro esempio potrebbe essere:
    n.ntkd.p2p.PID_12.msg_send(...)
n è un oggetto Neigh richiesto alla istanza locale di Neighbour. Attraverso l'attributo ntkd esegue una chiamata RPC. La root_instance (sull'host remoto) è l'oggetto NtkNode, il quale ha un attributo p2p che è una istanza della classe P2PAll. La classe P2PAll ha un attributo (dinamico) PID_12 che è una istanza della classe P2P. La classe P2P ha la funzione remotable msg_send. La chiamata quindi risulta corretta.

Invece il BcastClient viene istanziato e memorizzato sull'attributo broadcast dell'oggetto Radar.
Oppure si può istanziare un BcastClient all'abbisogna.

Quindi sul codice si trovano pezzi simili a questo:
    self.broadcast.radar.reply(...)
self.broadcast è un oggetto BcastClient attraverso il quale si esegue una chiamata RPC in broadcast. La root_instance (su tutti gli host Netsukuku della LAN) è l'oggetto NtkNode, il quale ha un attributo radar che è una istanza della classe Radar. La classe Radar ha la funzione remotable reply. La chiamata quindi risulta corretta.

Parametri formali speciali

TODO: spiegazione del _rpc_caller

Elenco dei metodi remotable

Modulo radar

  • class Radar(object)

    • reply                 Riceve _rpc_caller

    • time_register         Riceve _rpc_caller

  • class Neighbour(object)

    • ip_change

Modulo route

  • class MapRoute(Map)

    • free_nodes_nb

Modulo qspn

  • class Etp

    • etp_exec

Modulo hook

  • class Hook(object)

    • communicating_vessels

    • highest_free_nodes

Modulo p2p

  • class P2P(RPCDispatcher)

    • partecipant_add

    • msg_send

  • class P2PAll(object)

    • pid_getall

Modulo coord

  • class MapCache(Map)

    • map_data_merge

  • class Coord(P2P)

    • going_out

    • going_out_ok

    • going_in

Netsukuku/ita/ElencoRemotableFunctions (last edited 2009-05-25 17:02:52 by lukisi)