ITTO20010813A1 - Procedimento per il trasferimento di messaggi tramite udp, relativo sistema e prodotto informatico. - Google Patents
Procedimento per il trasferimento di messaggi tramite udp, relativo sistema e prodotto informatico. Download PDFInfo
- Publication number
- ITTO20010813A1 ITTO20010813A1 IT2001TO000813A ITTO20010813A ITTO20010813A1 IT TO20010813 A1 ITTO20010813 A1 IT TO20010813A1 IT 2001TO000813 A IT2001TO000813 A IT 2001TO000813A IT TO20010813 A ITTO20010813 A IT TO20010813A IT TO20010813 A1 ITTO20010813 A1 IT TO20010813A1
- Authority
- IT
- Italy
- Prior art keywords
- message
- udp
- payload
- snmp
- compression
- Prior art date
Links
- 238000012546 transfer Methods 0.000 title claims abstract description 22
- 238000000034 method Methods 0.000 title claims description 45
- 238000007906 compression Methods 0.000 claims abstract description 32
- 230000006835 compression Effects 0.000 claims abstract description 31
- 230000005540 biological transmission Effects 0.000 claims description 16
- 230000008569 process Effects 0.000 claims description 9
- 230000027455 binding Effects 0.000 claims description 8
- 238000009739 binding Methods 0.000 claims description 8
- 238000005538 encapsulation Methods 0.000 claims description 6
- 230000006837 decompression Effects 0.000 claims description 5
- 230000000295 complement effect Effects 0.000 claims description 2
- 230000006854 communication Effects 0.000 abstract description 5
- 238000004891 communication Methods 0.000 abstract description 5
- 238000010586 diagram Methods 0.000 description 12
- 230000004044 response Effects 0.000 description 5
- 230000006870 function Effects 0.000 description 4
- 238000007726 management method Methods 0.000 description 4
- 238000010276 construction Methods 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000012544 monitoring process Methods 0.000 description 2
- 238000003491 array Methods 0.000 description 1
- 230000008901 benefit Effects 0.000 description 1
- 230000007175 bidirectional communication Effects 0.000 description 1
- 230000002457 bidirectional effect Effects 0.000 description 1
- 238000013144 data compression Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000009977 dual effect Effects 0.000 description 1
- 238000002474 experimental method Methods 0.000 description 1
- 238000000605 extraction Methods 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 238000005457 optimization Methods 0.000 description 1
- 238000002360 preparation method Methods 0.000 description 1
- 238000012545 processing Methods 0.000 description 1
- 238000013519 translation Methods 0.000 description 1
- 230000014616 translation Effects 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H03—ELECTRONIC CIRCUITRY
- H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
- H03M7/00—Conversion of a code where information is represented by a given sequence or number of digits to a code where the same, similar or subset of information is represented by a different sequence or number of digits
- H03M7/30—Compression; Expansion; Suppression of unnecessary data, e.g. redundancy reduction
-
- H—ELECTRICITY
- H03—ELECTRONIC CIRCUITRY
- H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
- H03M7/00—Conversion of a code where information is represented by a given sequence or number of digits to a code where the same, similar or subset of information is represented by a different sequence or number of digits
- H03M7/30—Compression; Expansion; Suppression of unnecessary data, e.g. redundancy reduction
- H03M7/40—Conversion to or from variable length codes, e.g. Shannon-Fano code, Huffman code, Morse code
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/02—Standardisation; Integration
- H04L41/0213—Standardised network management protocols, e.g. simple network management protocol [SNMP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/04—Network management architectures or arrangements
- H04L41/046—Network management architectures or arrangements comprising network management agents or mobile agents therefor
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/04—Protocols for data compression, e.g. ROHC
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
- H04L69/161—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
- H04L69/164—Adaptation or special uses of UDP protocol
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
- H04L69/169—Special adaptations of TCP, UDP or IP for interworking of IP based networks with other networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/22—Parsing or analysis of headers
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Theoretical Computer Science (AREA)
- Communication Control (AREA)
- Computer And Data Communications (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Description
DESCRIZIONE dell'invenzione industriale dal titolo: "Procedimento per il trasferimento di messaggi tramite UDP, relativo sistema e prodotto informatico"
TESTO DELLA DESCRIZIONE
Campo dell'invenzione
La presente invenzione si riferisce al trasferimento dei messaggi che utilizzano un trasporto UDP (acronimo per User Datagram Protocol) quali ad esempio messaggi SNMP (acronimo per Simple Network Management Protocol).
Tali messaggi vengono generati e trasmessi nell'ambito delle reti informatiche quali internet. L'architettura dei protocolli internet è basata quattro livelli logici ossia applicazione (application), trasporto (transport), rete (network) e connessione (link).
I messaggi SNMP realizzano un semplice meccanismo di comunicazione fra una stazione di gestione (Network Manager System o NMS) ed i nodi gestiti. Ciò avviene tramite apposite applicazioni situate nei nodi stessi e denominate agent . I messaggi SNMP si innestano quindi sul livello UDP utilizzandolo appunto come trasporto.
Descrizione della tecnica nota
L'applicazione denominata agent (nel seguito indicata brevemente solo come "agent"), che dialoga con il rispettivo gestore di rete (NMS) attraverso i messaggi SNMP, ha associata una base dati correntemente denominata Management Information Base o, brevemente, MIB. In tale base dati vengono raccolte le informazioni relative alla gestione ed al monitoraggio del corrispondente elemento di rete. In particolare tali informazioni sono organizzate nel modo seguente :
- variabili MIB che possono essere lette dal Network Manager per ricavare informazioni sull'elemento di rete,
- variabili MIB che possono essere scritte dal Network Manager per causare azioni sull'elemento di rete, e
- eventi (trap) che 1'agent stesso può scatenare verso il manager a fronte di determinate situazioni .
La comunicazione a livello SNMP prevede quindi essenzialmente :
messaggi necessari a leggere/scrivere le suddette variabili (GetRequest, GetNextRequest, SetRequest, GetBulk), inviati dal Network Manager, e - messaggi di risposta (GetResponse) e di trap, inviati dall'agent.
L'insieme di tutte le variabili/trap gestite da un agent sono legate all'elemento di rete e ne rappresentano appunto la relativa MIB, e cioè espongono al manager lo stato di funzionamento e le caratteristiche intrinseche dell'elemento di rete.
Ogni variabile o trap è univocamente identificata da una stringa in notazione ASN.l (Abstract Syntax Notation One) detta Object IDentifier ovvero OID.
La relativa struttura è ad esempio del tipo "1.3.6.1.2.1.4.21", indicativa del fatto che la notazione ASN.l permette di rappresentare oggetti secondo una struttura gerarchica ad albero.
Una parte della MIB è stata definita come standard ed è supportata da qualunque agent, mentre altre variabili ed alcune trap sono specifiche per ogni costruttore ed in alcuni casi anche caratteristiche di una particolare tipologia di apparato .
Il protocollo SNMP, nato nel 1988, ha subito nel corso degli anni alcune evoluzioni. In particolare, sono state definite nuove tipologie di messaggi che gli agent deve essere in grado di interpretare e si è estesa la parte di MIB standard che ogni agent deve essere in grado di supportare. Al momento del deposito della presente domanda, le versioni utilizzate sono la 1 e la 2, mentre è in corso di standardizzazione la versione 3.
La dimensione di una MIB varia da apparato ad apparato e può essere anche dell'ordine di alcune centinaia di Kbyte, corrispondenti ad alcune centinaia di OID.
Lo schema riportato nella figura 1 dei disegni annessi illustra le tipiche componenti di un messaggio SNMP. Il contenuto di ogni componente è scritto con caratteri ASCII e la dimensione massima possibile è uguale alla dimensione massima di un messaggio UDP, l'entità dati che lo trasporta, pari a 65.507 byte o ottetti (di cui circa 64 kb utilizzabili per le informazioni da trasportare).
In particolare, nello schema della figura 1 è riconoscibile la presenza di un message header e di una parte PDU, di cui la parte indicata con 1 raccoglie i messaggi GetRequest, GetNextRequest , SetRequest e GetResponse, la parte indicata con 2 raccoglie i messaggi GetBulk, mentre la parte indicata con 3 indica in generale i messaggi di tipo trap.
In modo più specifico, nell'intestazione del messaggi SNMP sono inserite le seguenti informazioni :
- Version Number: numero della versione di SNMP utilizzata per la composizione del messaggio (VI, V2, V3, ...), e
Community Name: una sorta di password che consente di accedere in scrittura e/o in lettura agli oggetti contenuti nella MIB.
Nella PDU sono invece inserite le seguenti informazioni :
- PDU type: tipologia di messaggio, che nella versione 1 contiene i comandi GetRequest, GetNextRequest , SetRequest e Request, mentre nella versione 2 può contenere anche i comandi GetBulkRequest e InformRequest;
Request id: identificativo univoco del messaggio assegnato dal manager ed utilizzato dall'agent nella risposta affinché il manager possa associare la risposta richiesta a cui si riferisce;
- Error status: messo a 0 in tutte le tipologie di messaggio, fatta eccezione per le Response, in cui, se messo a 1, significa che si è verificato un errore;
- Error Index: indica quale, fra le variabili richieste (OID), ha provocato l'errore, e
- Variable Bindings: sono accoppiate OID/valore; i valori sono nulli nelle richieste e compilati nelle risposte.
In particolare, la parte più a sinistra della figura 1 illustra una tipica struttura della parte che raccoglie le suddette Variable Bindings.
Tanto nella presente descrizione, quanto nelle diciture che appaiono in alcune delle figure dei disegni annessi, è stata adottata la scelta di riportare - per i vari elementi di volta in volta considerati - i corrispondenti acronimi/ denominazioni /sigle in lingua inglese.
Questa scelta è stata fatta per evidenti motivi di chiarezza e semplicità di descrizione: i suddetti acronimi/denominazioni/sigle sono quelli correntemente adottati dagli esperti del settore a livello internazionale, non essendo stati sviluppati nel corso degli anni specifici traducenti nelle lingue nazionali.
La trasmissione del messaggio SNMP, resa possibile dall'UDP, consente lo scambio a pacchetto di dati fra due computer connessi alla rete. Il formato del messaggio UDP è appunto composto da un'intestazione (o header) le cui informazioni principali sono l'indirizzo IP del computer che invia il messaggio, l'indirizzo IP del computer a cui il messaggio è destinato e la dimensione della PDU trasportata. Il formato della PDU è composto a sua volta da una parte di intestazione e da una parte dati correntemente denominata "Payload" (carico utile) o "Octet Data". L'intestazione contiene dunque le seguenti informazioni: porta origine, porta destinazione, dimensione dell'unità trasportata, controllo di integrità (CHECKSUM) dell'unità dati.
La metodologia correntemente adottata per trasferire un messaggio SNMP su UDP (dal manager verso 1'agent o viceversa) prevede essenzialmente che il messaggio SNMP completo venga codificato utilizzando la metodologia BER (Basic Encoding Rules) . Questo modo di operare consente di trasporre i byte costituenti il messaggio SNMP in una struttura esadecimale adatta ad essere utilizzata come carico utile del messaggio UDP.
Il servizio di trasferimento UDP dei dati così ottenuti prevede essenzialmente:
in sede di invio: la lettura del messaggio SNMP e la successiva codifica esadecimale (BER encode) del messaggio, in vista della trasmissione su UDP, e
in sede di ricezione: dopo la ricezione su UDP, la decodifica esadecimale (BER decode) della PDU e la successiva ricostruzione del messaggio.
La pratica di applicazione corrente dimostra che nelle reti telematiche quali internet insorge la necessità di trasferire un'elevata quantità di informazioni in termini di richieste/risposte convogliate sotto forma di messaggi SNMP.
A causa della dimensione totale delle informazioni, del tempo necessario per il loro trasferimento e del traffico di rete generato, le soluzioni tradizionalmente impiegate per trasferire messaggi SNMP in formato standard si dimostrano assai poco efficienti.
Per questo motivo sono state già proposte - a livello di bozza - tre specifiche IETF destinate ad affrontare il problema.
La prima proposta (nota come SNMP Object Identifier Compression, rev. Aprii 2001 - draftietf-eos-oidcompression-OO.txt) si basa sul concetto che la maggioranza delle informazioni contenute nella MIB è referenziata da OID costituito da una parte costante molto grande e da una parte variabile molto piccola. Partendo da tale concetto, la proposta si pone come obiettivo quello di codificare, secondo un algoritmo, la parte costante dell'OID ottenendone una numerazione più breve. Tale soluzione ottimizza solo in parte la quantità di informazioni trasferite e non ne riduce in modo apprezzabile le dimensioni.
La seconda proposta (nota come "Efficient Transfer of Bulk SNMP Data, rev. Aprii 2001 - draftietf-eos-snmpbulk-00.txt") affronta il problema della gestione del comando GetBulk che consente la raccolta contemporanea di un certo insieme di informazioni. Il comando introdotto nella versione 2 di SNMP non consente di ottimizzare la raccolta in quanto in esso il manager è costretto a dichiarare il numero di elementi da raccogliere senza poter sapere da quanti elementi è composto il set di informazioni richiesto. Sono state quindi proposte soluzioni di modifica al protocollo UDP con la modifica dell'algoritmo di codifica del messaggio (da BER a PER - acronimo per Packet Encoding Rules) ovvero il ricorso ad una modalità di trasferimento di tipo FTP (acronimo per File Transfer Protocol). La soluzione proposta nel documento appena citato è l'introduzione di un nuovo comando sul lato agent, denominato GetColsRequest, e del relativo messaggio lato manager, in grado di riconoscere il numero di elementi da trasferire riconoscendo la fine del set richiesto ed ottimizzando quindi richieste e traffico dì rete. Anche questa soluzione proposta non consente però di gestire le dimensioni ed il numero di messaggi inviati.
La terza prosposta considerata (nota come "SNMP Payload Compression - rev. aprii 2001 - draft-irtfnmrg-snmp-compression-01.txt") è concettualmente simile alla prima proposta considerata in quanto propone un algoritmo di codifica differenziale denominato "OID Delta Compression" o ODC. A partire da un OID radice, tale soluzione prevede di memorizzare i successivi assegnando a questi un codice, associato all'OID radice, seguito dalla parte di OID variante. Sostanzialmente vengono memorizzate le variazioni in termini di incrementi differenziali rispetto all'elemento radice. Questa soluzione presenta l'inconveniente di non essere compatibile con precedenti versioni del protocollo. In più consente un risparmio stimato di circa il 30% per valori di OID molto ricorsivi, cioè array di dati e risulta sostanzialmente inefficiente se esistono poche ricorsività.
Scopi e sintesi dell'invenzione
La presente invenzione si prefigge lo scopo di fornire una soluzione alternativa rispetto a quella delineata in precedenza, tale da consentire di attuare un trasferimento ottimizzato su UDP di messaggi quali messaggi SNMP senza che ciò influenzi in modo negativo il protocollo e le prestazioni tanto dell'agent quanto del manager.
Secondo la presente invenzione, tale scopo viene raggiunto grazie ad un procedimento avente le caratteristiche richiamate in modo specifico nelle rivendicazioni che seguono. L'invenzione riguarda anche, in modo distinto, il relativo sistema nonché il prodotto informatico, direttamente caricabile nella memoria interna di un computer e comprendente porzioni di codice software per attuare il procedimento secondo l'invenzione quando il suddetto prodotto viene fatto girare su un computer.
In sostanza, la soluzione secondo l'invenzione si basa sulla compressione del messaggio completo (header e PDU). Sono in particolare previste due possibili diverse modalità di trasferimento. La prima incapsula il messaggio SNMP in un nuovo messaggio SNMP di tipo proprietario e lo invia in modalità standard utilizzando UDP. La seconda pilota direttamente UDP attraverso un driver fornendo come contenuto dati (Data Octet) il risultato della compressione del messaggio SNMP.
La tecnica di compressione si basa essenzialmente sul riconoscimento di sequenze che compaiono periodicamente nel messaggio.
In una forma di attuazione dell'invenzione particolarmente preferita, viene utilizzata, quale tecnica di compressione, una variante della tecnica nota come LZ77 (si veda al riguardo il lavoro di Ziv. J., Lempel A., "A Universal Algorithm for Sequential Data Compression", IEEE Transactions on Information Theory, Voi. 23, No. 3, pp. 337-343) ben conosciuto in ambiente UNIX e denominata gzip (gzip format - RFC 1952) utilizzata anche dal più popolare PKZIP. Le specifiche di tale tecnica sono di pubblico dominio e sono altresì disponibili librerie sorgenti che implementano ed utilizzano questa soluzione per diversi ambienti di sviluppo e sistemi operativi come HP-UX,Digital , BeOS, Linux, OS/2, Java, Win32, WinCE.
In particolare è possibile utilizzare un porting dell'algoritmo su Win32 utilizzando la libreria ”zLib" : al riguardo si può utilmente consultare il sito http://www.info-zip.org/pub/infozip/zlib/. La caratteristica principale di questa libreria è quella di consentire la compressione runtime e onmemory sia di strutture dati binarie, sia di stringhe, fattore importante per le prestazioni del sistema .
Descrizione particolareggiata dei disegni annessi
L'invenzione verrà ora descritta, a puro titolo di esempio non limitativo, con riferimento ai disegni annessi, nei quali:
- la Figura 1, relativa alla tecnica nota, è già stata descritta in precedenza,
la Figura 2 illustra, sotto forma di un generale schema a blocchi, una tipica architettura di applicazione della soluzione secondo 1'invenzione,
- le Figure 3 a 5, ciascuna suddivisa in due parti, rispettivamente relative alla trasmissione (parte a) ed alla ricezione (parte b), illustrano diverse forme di attuazione della soluzione secondo l'invenzione sotto forma di diagrammi di flusso, - la Figura 6 è un'ulteriore diagramma di flusso illustrativo delle caratteristiche più generali della soluzione secondo l'invenzione, e
- le Figure 7 e 8 illustrano, secondo modalità sostanzialmente affini a quelle adottate nella figura 1, i criteri di realizzazione della soluzione secondo l'invenzione, illustrata in due possibili varianti .
Descrizione particolareggiata di un esempio di attuazione dell'invenzione
Con riferimento allo schema generale della figura 2, il riferimento N indica una rete telematica (si pensi con immediato riferimento ad internet) definente il tipico ambiente di applicazione della soluzione secondo l'invenzione.
Il riferimento A indica il modulo correntemente denominato agent, che svolge la funzione di controllo e di monitoraggio di un corrispondente elemento della rete N in rapporto di dialogo bidirezionale - con un corrisponente manager M.
Quest'ultimo definisce, insieme ad un ulteriore agent A' di livello gerarchico più elevato, una porta o gate G che a sua volta si interfaccia con un ulteriore manager M' di livello gerarchico più elevato .
Quest'ultimo definisce, insieme ad una corrispondente applicazione, un modulo di osservazione o observer 0.
I riferimenti CI e C2 indicano due canali di comunicazione bidirezionale che realizzano la comunicazione - a livello gerarchico più basso - tra agent A e gate G e - a livello gerarchico più elevato - fra gate G e observer 0.
I suddetti canali Cl, C2 sono quelli su cui si realizza la trasmissione dei messaggi SNMP.
I diagrammi di flusso della figura 3 illustrano le modalità adottate per la compressione (figura 3a) e la decompressione (figura 3b) del messaggio SNMP.
I diagrammi di flusso della figura 4 illustrano (sempre riferendosi rispettivamente alla trasmissione - figura 4a - ed alla ricezione figura 4b) una prima soluzione che prevede il trasferimento del messaggio SNMP compresso attraverso incapsulamento su SNMP.
I diagrammi di flusso della figura 5 si riferiscono invece ad una soluzione di trasferimento attraverso incapsulamento su UDP. Questo sempre con riferimento distinto alla trasmissione (figura 5a) ed alla ricezione (figura 5b).
Gli schemi delle figure 7 e 8, riproducono in relazione alla rappresentazione dell'OID lo stesso formalismo della figura 1 e si riferiscono al complesso delle operazioni di compressione e trasmissione esemplificati, rispettivamente, dalla parte a) delle figure 3 e 4 (figura 7) e dalla parte a) delle figure 3 e 5 (figura 8).
Esaminando dapprima il diagramma di flusso della figura 3, il riferimento 100 identifica la fase in cui l'intero messaggio SNMP (header PDU) viene letto per poi essere convertito, in una successiva fase indicata con 102 in formato esadecimale. Ciò avviene applicando una codifica del tipo BER encode.
Il messaggio così codificato viene quindi compresso on-memory utilizzando una tecnica di compressione basata sul riconoscimento di sequenze ricorsive quale ad esempio la tecnica documentata nella libreria zLib già citata in precedenza.
Ciò avviene in una fase indicata con 104 così da ottenere, nella fase indicata con 106, un'unità dati (Data Unit) compressa e pronta per la trasmissione.
In modo del tutto simmetrico, il diagramma di flusso della parte b della figura 3 comprende quattro fasi 206, 204, 202 e 200 (destinate ad essere svolte nella sequenza indicata), in cui l'unità dati compressa ricevuta (fase 206), viene sottoposta a decompressione (fase 204) in vista della successiva decodifica esadecimale (fase 202) con successiva ricostruzione dell'interno messaggio SNMP (fase 200).
Il fatto di aver attribuito alle fasi del diagramma di flusso della parte b) della figura 3 riferimenti numerici ordinati in modo inverso rispetto alla loro sequenza di attuazione è destinata unicamente a mettere in luce il carattere di simmetria con le fasi 100 a 106 del procedimento di compressione. Analoghe scelte sono state fatte con riferimento ai diagrammi di flusso della figura 4 e della figura 5.
Come già indicato, la figura 4 e la figura 7 si riferiscono ad una soluzione di trasferimento che prevede l'incapsulamento dell'unità dati compressa in un messaggio SNMP standard caratterizzato da un Variable Binding proprietario con invio in modalità standard su UDP.
La metodologia di incapsulamento della Data Unit compressa ottenuta nella fase 106 prevede in una fase iniziale, indicata con 108, che l'unità dati compressa venga letta in byte per poi essere trasposta, in una successiva fase di codifica indicata con 110, nel corrispettivo insieme di caratteri ASCII.
Nella successiva fase indicata con 112 (eventualmente preceduta da funzioni ausiliarie quali ACK TAB NULL - si veda il blocco 110a della figura 7) viene generato il "Variable Binding" del messaggio costituito da un primo OID con una numerazione proprietaria (ad esempio 1.3.6.1.4.666.1) che contiene nel suo valore la stringa _ZIP_xxxx, dove xxxx rappresenta la dimensione del file originale. Nell'esempio sopra citato è stato indicato il codice proprietario 666.1 che - al momento - non risulta registrato presso la IANA - Internet Assigned Numbers Authority.
I successivi elementi del Variable Binding che contengono l'unità dati compressa tradotta in ASCII sono costituiti da coppie OID/valore. Il valore contiene porzioni dell'unità dati compressa e trasposta in ASCII della dimensione massima di 255 caratteri.
Vengono quindi ricostruite le informazioni di header del messaggio SNMP. Tutto ciò avviene nella fase 112 che è seguita da una fase indicata con 114 in cui si realizza un'ulteriore codifica secondo la metodologia BER mirante a generare il carico utile (payload) della PDU UDP destinato ad essere impiegato per l'invio dei dati (fase 116).
Anche in questo caso, le fasi indicate con 216, 214, 212, 210 e 208 riprodotte nella parte b) della figura 4 e destinate ad essere attuate nell'ordine in cui sono state citate in precedenza, rappresentano le funzioni duali - destinate ad essere attuate in ricezione - delle fasi 108 a 116 relative all'operazione di trasmissione.
Adottando la soluzione a cui si riferiscono le figure 4 e 7, il messaggio SNMP compresso ha quindi un formato logico SNMP standard, ma un contenuto proprietario. Esso richiede quindi un'estensione funzionale - peraltro minimale - del manager dell'agent tale da consentire il riconoscimento e la codifica/decodifica .
Le esperienze condotte dalla Richiedente dimostrano che tale soluzione è del tutto fattibile senza incidenza negativa sull'architettura di rete.
La soluzione alternativa a cui fanno riferimento le figure 5 e 8 prevede la preparazione dell'unità dati compressa a partire dal messaggio SNMP secondo le modalità illustrate nella figura 3 seguita dal diretto incapsulamento di tale unità dati nel carico utile della PDU UDP.
Naturalmente, per funzionare correttamente, questa soluzione richiede la disponibilità di un trasmettitore e di un ricevitore dedicati, ad esempio in condizioni che prevedono la disponibilità di una porta UDP diversa da quella standard. Il trasmettitore deve quindi conoscere la porta UDP utilizzata dal ricevitore e viceversa. Le informazioni sulle porte utilizzate possono essere scambiate, a livello superiore, utilizzando un messaggio di sincronizzazione in formato SNMP standard secondo i criteri meglio illustrati nel seguito .
Adottando la soluzione alternativa illustrata nelle figure 5 e 8, l'unità dati compressa resa disponibile nella fase 108 e destinata a sostituire il BER del messaggio - diventa il carico utile del messaggio UDP.
La relativa operazione è schematizzata dalla fase indicata con 120 nelle figure 5 e 8, fase che precede la fase di trasmissione 122 destinata alla rispettiva porta dedicata (denominata in generale porta X) del ricevitore.
Anche in questo caso, l'operazione complementare si articola su tre fasi indicate rispettivamente con 222 (ricezione sulla porta Y del modulo che al momento funge da ricevitore), 220 (estrazione del carico utile della PDU UDP) e 218 (ottenimento dell'unità dati compressa ricevuta destinata ad essere trasferita verso la fase 206 del diagramma di flusso della parte b della figura 3).
Anche in questo caso le fasi 222, 220 e 218 vengono svolte nell'ordine con cui sono state citate .
Il messaggio di sincronizzazione a cui si faceva riferimento in precedenza è inviato dal manager all'agent SNMP secondo un generale criterio applicazione-per -applicazione (application-toapplication) utilizzando il formato SNMP standard contenente un Variable Binding proprietario.
Le informazioni trasferite possono essere del tipo
Il manager invia al manager SNMP un messaggio proprietario compilando il valore <UDP_TX_Port> con il numero della porta destinata ad essere utilizzata per la trasmissione UDP (ad esempio 1024) nonché un valore <UDP_RX_Port> con il numero della porta che utilizzerà per la ricezione UDP (ad esempio 1224). L'agent risponde al manager con un messaggio analogo ma contenente le proprie informazioni. Questo metodo riduce il tempo di elaborazione migliorando l'efficienza della soluzione.
Lo schema a blocchi della figura 6 fa ulteriormente vedere come la soluzione descritta possa essere generalizzata così da poter essere applicata a qualunque tipologia di messaggio che utilizza UDP come trasporto (ad esempio SNMP, PING, ecc .). Tale generalizzazione consente di realizzare un driver UDP in grado di sostituire quelli attualmente utilizzati.
Questa soluzione prevede di valutare la dimensione del carico utile da trasferire procedendo quindi, se le dimensioni risultano opportune (ad esempio, maggiore di 20 byte), utilizzando il metodo descritto. Al fine di dichiarare al ricevente la natura compatta del messaggio UDP si possono utilizzare gli 8 bit compresi dal bit 62 al bit 69 dell'header del messaggio UDP (attualmente tali bit non vengono utilizzati e sono posti di default a valore 0) ponendo a 1 ad esempio uno i più di tali bit.
In particolare, nello schema della figura 6 il riferimento 300 indica una qualunque fase in cui si generi l'esigenza di inviare un messaggio suscettibile di essere trasportato su UDP seguito da una fase 302 di compressione del carico utile, attuato secondo le modalità descritte in precedenza.
Una successiva fase 304 prevede la generazione dell'header del messaggio UDP nei termini richiamati in precedenza, mentre una successiva fase indicata con 306 corrisponde alla creazione del messaggio UDP completo in vista della sua trasmissione IP, attuata in una fase indicata con 308.
La metodologia descritta consente di realizzare una soluzione di tipo generai purpose in grado di supportare qualunque tipo di applicazione che utilizzi la catena protocollare UDP-IP. Tale soluzione è particolarmente adatta alla realizzazione di soluzioni "on chip".
Un'estensione funzionale della soluzione descritta, applicabile in modo indipendente dalla metodologia utilizzata per il trasferimento dei dati, e la cifratura del messaggio o del suo equivalente BER oppure Data Octet UDP. Al riguardo un metodo sicuro ed efficiente da utilizzare risulta essere quello correntemente denominato come "block cipher Rijndael", correntemente denominato anche AES.
La soluzione descritta presenta il vantaggio di consentire la compressione dei messaggi SNMP superando gli inconvenienti delineati nella parte introduttiva della descrizione - facendo riferimento ad una tecnica di compressione flessibile, di tipo consolidato ma aperto anche ad altre tecniche di compressione (ad esempio MPEG). Tale tecnica, e il relativo algoritmo, sono utilizzabili in molti sistemi operativi rendendo la soluzione proposta riutilizzabile e reimplementabile. Si tratta altresì di una soluzione che ha un impatto minimo sia sul manager sia sull'agent, in quanto richiede la costruzione di una semplice sovrastruttura per la compressione e decompressione dei messaggi.
La soluzione si dimostra altresì efficiente in quanto consente di ottimizzare il traffico in rete trasferendo, a parità di tempo, un maggior numero di informazioni oppure la stessa quantità di informazioni in un minor numero di messaggi. Si tratta altresì di una soluzione sicura, in quanto le informazioni viaggiano sulla rete non in chiaro in quanto compresse e codificate.
Naturalmente, fermo restando il principio dell'invenzione, i particolari di realizzazione e le forme di attuazione potranno essere ampiamente variati rispetto a quanto descritto ed illustrato, senza per questo uscire dall'ambito della presente invenzione .
Claims (17)
- RIVENDICAZIONI 1. Procedimento per trasferire su UDP (User Datagram Protocol) messaggi comprendenti un carico utile (OID) , caratterizzato dal fatto che comprende l'operazione di sottoporre almeno detto carico utile ad un' operazione di compressione (302; 104, 204) basata sul riconoscimento di sequenze che compaiono periodicamente nel messaggio.
- 2. Procedimento secondo la rivendicazione 1, caratterizzato dal fatto che detta operazione di compressione viene svolta secondo una tecnica di tipo gzip quale zLib.
- 3. Procedimento secondo la rivendicazione 1 o la rivendicazione 2, caratterizzato dal fatto che comprende l'operazione di indicare 1'avvenuta compressione nel messaggio trasferito tramite UDP.
- 4. Procedimento secondo la rivendicazione 3, caratterizzato dal fatto che per indicare l'avvenuta operazione di compressione (302) viene utilizzato un campo di bit dell'header UDP.
- 5. Procedimento secondo la rivendicazione 4, caratterizzato dal fatto che per indicare 1'avvenuta operazione di compressione (302) vengono utilizzati i bit compresi dal bit 62 al bit 69 dell'header UDP.
- 6. Procedimento secondo la rivendicazione 5, caratterizzato dal fatto che comprende l'operazione di porre ad 1 almeno uno fra i bit 62 a 69 dell'header del messaggio UDP.
- 7. Procedimento secondo una qualsiasi delle rivendicazioni 1 a 6, applicato al trasferimento di messaggi SNMP, caratterizzato dal fatto che, in fase di compressione, comprende le operazioni di: - leggere (100) l'intero messaggio SNMP, - codificare (102) il messaggio letto in formato esadecimale, e sottoporre il messaggio codificato in forma esadecimale all'operazione di compressione (104).
- 8. Procedimento secondo una qualsiasi delle rivendicazioni 1 a 7, applicato al trasferimento di messaggi SNMP, caratterizzato dal fatto che, in fase di ricezione, comprende le operazioni di: sottoporre il messaggio ricevuto ad un'operazione di de-compressione (204) complementare a detta operazione di compressione, così da ottenere un messaggio sottoposto a decompressione in formato esadecimale, - decodificare (202) il messaggio sottoposto a de-compressione (204) a partire dal formato esodecimale, e - ricostruire (200) l'intero messaggio SNMP a partire dal messaggio decodificato a partire dal formato esadecimale.
- 9. Procedimento secondo la rivendicazione 7 o la rivendicazione 8, caratterizzato dal fatto che comprende l'operazione di incapsulare ai fini del trasferimento il messaggio sottoposto a detta operazione di compressione (104) in un messaggio SNMP standard.
- 10. Procedimento secondo la rivendicazione 9, caratterizzato dal fatto che, in sede di trasmissione, comprende le operazioni di: - leggere (108) il messaggio sottoposto a detta operazione di compressione (104) in byte, trasponendolo (110) in un corrispondente messaggio in caratteri ASCII, - generare (112) un insieme di variable binding comprendente un primo OID indicativo della dimensione del file originale e successive coppie OID/valore che veicolano porzioni di detto messaggio sottoposto a detta operazione di compressione (104) trasposto in caratteri ASCII, ricostruire le informazioni di header del messaggio SNMP, codificare (114) il messaggio SNP così ottenuto in formato esadecimale così da generare carico utile UDP, e - trasferire (116) il carico utile così generato tramite UDP.
- 11. Procedimento secondo la rivendicazione 9 o la rivendicazione 10, caratterizzato dal fatto che, in sede di ricezione, comprende le operazioni di: ricevere il messaggio sottoposto a detta operazione di compressione come carico utile UDP (216) , - sottoporre il carico utile così ricevuto ad un'operazione di decodifica esadecimale (214), riconoscere ed assemblare (212) il variable binding del messaggio sottoposto a decodifica esodecimale , sottoporre il messaggio sottoposto a detta operazione di riconoscimento ed assemblaggio (212) ad un'operazione di decodifica da ASCII a binario (210), e - sottoporre il messaggio decodificato in forma binaria a detta operazione di de-compressione (204) .
- 12. Procedimento secondo la rivendicazione 7 o la rivendicazione 8, caratterizzato dal fatto che comprende l'operazione di integrare il messaggio sottoposto a detta operazione di compressione (104) tramite incapsulamento su UDP.
- 13. Procedimento secondo la rivendicazione 12, caratterizzato dal fatto che, in fase di trasmissione, comprende le operazioni di: - configurare detto messaggio sottoposto a detta operazione di compressione (104) come carico utile di Protocol Data Unit (PDU), e - trasferire il carico utile così creato verso una porta data di un ricevitore.
- 14. Procedimento secondo la rivendicazione 12 o la rivendicazione 13, caratterizzato dal fatto che, in sede di ricezione, comprende le operazioni di: - ricevere detto messaggio come carico utile di una PDU UDP ricevuta su una porta di ricevitore, e - estrarre detto carico utile da detta PDU.
- 15. Procedimento secondo la rivendicazione 13 o la rivendicazione 14, caratterizzato dal fatto che comprende l'operazione di trasmettere fra un terminale trasmittente (M, M'; A, A' ) ed un terminale ricevente (A, A'; M, M') un messaggio di sincronizzazione di tipo SNMP identificativo di detta porta di trasmissione e/o di detta porta di ricezione .
- 16. Sistema per la gestione di reti telematiche, comprendente almeno un'unità manager (M, M') ed almeno un'unità agent (A, A') che comunicano fra loro su almeno un canale (Cl, C2) attraverso la trasmissione di messaggi, caratterizzato dal fatto che detti messaggi vengono trasferiti su UDP con il procedimento secondo una qualsiasi delle rivendicazioni 1 a 15.
- 17. Prodotto informatico direttamente caricabile nella memoria interna di un elaboratore numerico e comprendente porzioni di codice software per attuare il procedimento secondo una qualsiasi delle rivendicazioni 1 a 15 quando il prodotto viene fatto girare su un elaboratore numerico.
Priority Applications (13)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| IT2001TO000813A ITTO20010813A1 (it) | 2001-08-13 | 2001-08-13 | Procedimento per il trasferimento di messaggi tramite udp, relativo sistema e prodotto informatico. |
| PCT/IT2002/000533 WO2003017618A1 (en) | 2001-08-13 | 2002-08-09 | Method and device for the transfer of snmp messages over udp with compression of periodically repeating sequences |
| AT02775199T ATE324737T1 (de) | 2001-08-13 | 2002-08-09 | Verfahren und einrichtung zum transfer von snmp- nachrichten über udp mit komprimierung sich periodisch wiederholender sequenzen |
| CN028158814A CN1541475B (zh) | 2001-08-13 | 2002-08-09 | 传输用户数据报协议消息的方法 |
| CA2456912A CA2456912C (en) | 2001-08-13 | 2002-08-09 | Method and device for the transfer of snmp messages over udp with compression of periodically repeating sequences |
| JP2003521584A JP2005500606A (ja) | 2001-08-13 | 2002-08-09 | 周期的に繰り返すシーケンスの圧縮によるｕｄｐ上でのｓｎｍｐメッセージの転送方法及び装置 |
| CN2010101343871A CN101854252B (zh) | 2001-08-13 | 2002-08-09 | 利用周期重复序列压缩通过udp传输snmp消息的方法和装置 |
| KR1020047002221A KR100942243B1 (ko) | 2001-08-13 | 2002-08-09 | 주기적으로 반복하는 시퀀스를 압축하여 ｕｄｐ를 통해ｓｎｍｐ 메세지를 전송하기 위한 방법 및 장치 |
| EP02775199A EP1417821B1 (en) | 2001-08-13 | 2002-08-09 | Method and device for the transfer of snmp messages over udp with compression of periodically repeating sequences |
| ES02775199T ES2263820T3 (es) | 2001-08-13 | 2002-08-09 | Metodo y dispositivo para transferir mensajes snmp por udp con compresion de secuencias que se repiten periodicamente. |
| DE60210986T DE60210986T2 (de) | 2001-08-13 | 2002-08-09 | Verfahren und vorrichtung zur übertragung von snmp-nachrichten mittels udp mit kompriierung sich periodisch wiederholdender sequenzen |
| US10/486,738 US7734825B2 (en) | 2001-08-13 | 2002-08-09 | Transferring SNMP messages over UDP with compression of periodically repeating sequences |
| US12/791,350 US20100306414A1 (en) | 2001-08-13 | 2010-06-01 | Transferring of SNMP Messages Over UDP with Compression of Periodically Repeating Sequences |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| IT2001TO000813A ITTO20010813A1 (it) | 2001-08-13 | 2001-08-13 | Procedimento per il trasferimento di messaggi tramite udp, relativo sistema e prodotto informatico. |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| ITTO20010813A0 ITTO20010813A0 (it) | 2001-08-13 |
| ITTO20010813A1 true ITTO20010813A1 (it) | 2003-02-13 |
Family
ID=11459150
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| IT2001TO000813A ITTO20010813A1 (it) | 2001-08-13 | 2001-08-13 | Procedimento per il trasferimento di messaggi tramite udp, relativo sistema e prodotto informatico. |
Country Status (11)
| Country | Link |
|---|---|
| US (2) | US7734825B2 (it) |
| EP (1) | EP1417821B1 (it) |
| JP (1) | JP2005500606A (it) |
| KR (1) | KR100942243B1 (it) |
| CN (2) | CN101854252B (it) |
| AT (1) | ATE324737T1 (it) |
| CA (1) | CA2456912C (it) |
| DE (1) | DE60210986T2 (it) |
| ES (1) | ES2263820T3 (it) |
| IT (1) | ITTO20010813A1 (it) |
| WO (1) | WO2003017618A1 (it) |
Families Citing this family (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| ITTO20010813A1 (it) * | 2001-08-13 | 2003-02-13 | Telecom Italia Lab Spa | Procedimento per il trasferimento di messaggi tramite udp, relativo sistema e prodotto informatico. |
| CN100452656C (zh) | 2003-06-06 | 2009-01-14 | 诺基亚有限公司 | 用于应用消息压缩及解压缩的方法和设备 |
| US7716355B2 (en) * | 2005-04-18 | 2010-05-11 | Cisco Technology, Inc. | Method and apparatus for processing simple network management protocol (SNMP) requests for bulk information |
| EP1768308B1 (en) * | 2005-09-26 | 2008-04-02 | Alcatel Lucent | Data distribution to nodes of a telecommunication network |
| CN1949765B (zh) * | 2005-10-10 | 2010-10-13 | 华为技术有限公司 | 获得被管设备的ssh主机公开密钥的方法和系统 |
| GB2441371A (en) * | 2006-08-29 | 2008-03-05 | Motorola Inc | Transmitting packets across a network by compressing and encapsulating them |
| US7865610B2 (en) | 2007-03-12 | 2011-01-04 | Nautel Limited | Point to multipoint reliable protocol for synchronous streaming data in a lossy IP network |
| CN103023702A (zh) * | 2012-12-14 | 2013-04-03 | 武汉烽火网络有限责任公司 | 批量mib的处理方法 |
| EP3235174A4 (en) * | 2014-12-19 | 2018-09-19 | Thomson Licensing | Method and apparatus for data transfer between network devices |
Family Cites Families (30)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5790599A (en) * | 1989-01-19 | 1998-08-04 | Redband Technologies, Inc. | Data compression system using source representation |
| US6144859A (en) * | 1993-08-27 | 2000-11-07 | Aeris Communications, Inc. | Wireless cellular communicator system and apparatus |
| US6026232A (en) * | 1995-07-13 | 2000-02-15 | Kabushiki Kaisha Toshiba | Method and system to replace sections of an encoded video bitstream |
| US5649189A (en) * | 1995-11-29 | 1997-07-15 | 3Com Corporation | Method and apparatus for single pass data encoding of binary words using a stack for writing in reverse order |
| US6073180A (en) * | 1996-03-07 | 2000-06-06 | Nippon Telegraph And Telephone Corporation | High-speed batch file transfer method and apparatus, and storage medium in which a program for executing the transfer is stored |
| JPH09331332A (ja) * | 1996-06-10 | 1997-12-22 | Fujitsu Ltd | コネクション識別子のネゴシエーション方法 |
| US6108782A (en) * | 1996-12-13 | 2000-08-22 | 3Com Corporation | Distributed remote monitoring (dRMON) for networks |
| US6441920B1 (en) * | 1997-06-04 | 2002-08-27 | Agfa Corporation | System and method for output management |
| US6044468A (en) * | 1997-08-25 | 2000-03-28 | Emc Corporation | Secure transmission using an ordinarily insecure network communication protocol such as SNMP |
| US6189045B1 (en) * | 1998-03-26 | 2001-02-13 | International Business Machines Corp. | Data type conversion for enhancement of network communication systems |
| US6519635B1 (en) * | 1998-04-30 | 2003-02-11 | Cisco Technology, Inc. | SNMP master agent that translates messages to a sub-agent proprietary format using a translation table by the sub-agent |
| IT1302431B1 (it) * | 1998-08-12 | 2000-09-05 | Alasi Di Arcieri Franco & C S | Dispositivo di controllo di accessi in rete tramite il riconoscimentoveloce di trame applicative che soddisfano un insieme di regole |
| WO2000057284A1 (en) * | 1999-03-25 | 2000-09-28 | Motorola Inc. | Point to point protocol multiplexing/demultiplexing method and apparatus |
| CA2280662A1 (en) * | 1999-05-21 | 2000-11-21 | Joe Toth | Media server with multi-dimensional scalable data compression |
| US6542504B1 (en) * | 1999-05-28 | 2003-04-01 | 3Com Corporation | Profile based method for packet header compression in a point to point link |
| US6427149B1 (en) * | 1999-09-09 | 2002-07-30 | Herman Rodriguez | Remote access of archived compressed data files |
| US7600039B2 (en) * | 2000-02-16 | 2009-10-06 | Motorola, Inc. | Label-based multiplexing |
| US20020002611A1 (en) * | 2000-04-17 | 2002-01-03 | Mark Vange | System and method for shifting functionality between multiple web servers |
| US7197046B1 (en) * | 2000-08-07 | 2007-03-27 | Shrikumar Hariharasubrahmanian | Systems and methods for combined protocol processing protocols |
| US6618397B1 (en) * | 2000-10-05 | 2003-09-09 | Provisionpoint Communications, Llc. | Group packet encapsulation and compression system and method |
| US6883035B2 (en) * | 2000-11-16 | 2005-04-19 | Telefonaktiebolaget Lm Ericsson (Publ) | System and method for communicating with temporary compression tables |
| JP3565266B2 (ja) * | 2000-12-28 | 2004-09-15 | 日本電気株式会社 | ネットワークの管理方法およびそのシステム |
| US6459392B1 (en) * | 2001-01-19 | 2002-10-01 | International Business Machines Corporation | Technique for encoding a sequence of periodic byte values with vertical correlation |
| ITTO20010813A1 (it) * | 2001-08-13 | 2003-02-13 | Telecom Italia Lab Spa | Procedimento per il trasferimento di messaggi tramite udp, relativo sistema e prodotto informatico. |
| KR100431003B1 (ko) * | 2001-10-31 | 2004-05-12 | 삼성전자주식회사 | 데이터 송수신 시스템 및 방법 |
| US7221684B1 (en) * | 2002-01-08 | 2007-05-22 | Cisco Technology, Inc. | Increasing network efficiency using packet compression and decompression |
| US6711740B1 (en) * | 2002-01-17 | 2004-03-23 | Cisco Technology, Inc. | Generic code book compression for XML based application programming interfaces |
| US7519729B2 (en) * | 2002-02-27 | 2009-04-14 | Ricoh Co. Ltd. | Method and apparatus for monitoring remote devices through a local monitoring station and communicating with a central station supporting multiple manufacturers |
| ITTO20020325A1 (it) * | 2002-04-12 | 2003-10-13 | Telecom Italia Lab Spa | ,,procedimento per organizzare la comunicazione fra oggetti gestori ed oggetti gestiti in una rete telematica.relativa architettura e prodot |
| US7362780B2 (en) * | 2002-12-11 | 2008-04-22 | Nokia Corporation | Avoiding compression of encrypted payload |
-
2001
- 2001-08-13 IT IT2001TO000813A patent/ITTO20010813A1/it unknown
-
2002
- 2002-08-09 AT AT02775199T patent/ATE324737T1/de not_active IP Right Cessation
- 2002-08-09 EP EP02775199A patent/EP1417821B1/en not_active Expired - Lifetime
- 2002-08-09 ES ES02775199T patent/ES2263820T3/es not_active Expired - Lifetime
- 2002-08-09 KR KR1020047002221A patent/KR100942243B1/ko not_active Expired - Fee Related
- 2002-08-09 CA CA2456912A patent/CA2456912C/en not_active Expired - Fee Related
- 2002-08-09 US US10/486,738 patent/US7734825B2/en not_active Expired - Fee Related
- 2002-08-09 DE DE60210986T patent/DE60210986T2/de not_active Expired - Lifetime
- 2002-08-09 JP JP2003521584A patent/JP2005500606A/ja active Pending
- 2002-08-09 CN CN2010101343871A patent/CN101854252B/zh not_active Expired - Fee Related
- 2002-08-09 CN CN028158814A patent/CN1541475B/zh not_active Expired - Fee Related
- 2002-08-09 WO PCT/IT2002/000533 patent/WO2003017618A1/en not_active Ceased
-
2010
- 2010-06-01 US US12/791,350 patent/US20100306414A1/en not_active Abandoned
Also Published As
| Publication number | Publication date |
|---|---|
| US20100306414A1 (en) | 2010-12-02 |
| KR20040030967A (ko) | 2004-04-09 |
| ES2263820T3 (es) | 2006-12-16 |
| CN1541475B (zh) | 2011-10-26 |
| WO2003017618A1 (en) | 2003-02-27 |
| CN101854252A (zh) | 2010-10-06 |
| DE60210986D1 (de) | 2006-06-01 |
| CN1541475A (zh) | 2004-10-27 |
| ATE324737T1 (de) | 2006-05-15 |
| CA2456912C (en) | 2013-12-24 |
| EP1417821B1 (en) | 2006-04-26 |
| EP1417821A1 (en) | 2004-05-12 |
| JP2005500606A (ja) | 2005-01-06 |
| KR100942243B1 (ko) | 2010-02-16 |
| DE60210986T2 (de) | 2007-01-11 |
| ITTO20010813A0 (it) | 2001-08-13 |
| US7734825B2 (en) | 2010-06-08 |
| CA2456912A1 (en) | 2003-02-27 |
| CN101854252B (zh) | 2012-07-11 |
| US20050038912A1 (en) | 2005-02-17 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US20100306414A1 (en) | Transferring of SNMP Messages Over UDP with Compression of Periodically Repeating Sequences | |
| JP3751823B2 (ja) | 実時間サービスにおけるヘッダ圧縮 | |
| US8934343B2 (en) | Method and apparatus for Ethernet data compression | |
| CN101436922B (zh) | 一种基于udp协议传输大量数据的方法 | |
| EP3641272B1 (en) | Header compression for ccn messages using a static dictionary | |
| CN102118792B (zh) | 一种传输数据包的方法及装置 | |
| US20080126378A1 (en) | Method and system for certificate revocation list compression | |
| CN112335203B (zh) | 处理局域网诊断数据 | |
| US11251905B2 (en) | Method for receiving code block stream, method for transmitting code block stream, and communications apparatus | |
| EP2071808A1 (en) | Methods and a system and devices for ipv6 datagram transmission in the ethernet | |
| CA2482429C (en) | Method for organising communication between manager objects and managed objects in a communication network, architecture and software thereof | |
| CN116032440A (zh) | 一种数据处理方法、设备、系统以及介质 | |
| CN101183936B (zh) | 一种因特网密钥交换中IPv6身份载荷交换的方法 | |
| GB2587427A (en) | Processing local area network diagnostic data | |
| CN110417814A (zh) | 报文的空口传输处理方法、装置和通信设备 | |
| West et al. | IP header and signalling compression for 3G systems | |
| US20030043806A1 (en) | Method and system for delineating data segments subjected to data compression | |
| Hübner | Communication and Networked Systems | |
| Neupane | IP payload compression for higher throughput |