WO2012124999A2 - 단말의 리소스 제공 방법 및 서버의 리소스 획득 방법 - Google Patents

단말의 리소스 제공 방법 및 서버의 리소스 획득 방법 Download PDF

Info

Publication number
WO2012124999A2
WO2012124999A2 PCT/KR2012/001897 KR2012001897W WO2012124999A2 WO 2012124999 A2 WO2012124999 A2 WO 2012124999A2 KR 2012001897 W KR2012001897 W KR 2012001897W WO 2012124999 A2 WO2012124999 A2 WO 2012124999A2
Authority
WO
WIPO (PCT)
Prior art keywords
resource
cache
node
type
server
Prior art date
Application number
PCT/KR2012/001897
Other languages
English (en)
French (fr)
Other versions
WO2012124999A3 (ko
Inventor
박승규
김성윤
고팔라 라주 엔.라마
Original Assignee
엘지전자 주식회사
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 엘지전자 주식회사 filed Critical 엘지전자 주식회사
Priority to US14/005,802 priority Critical patent/US20140012939A1/en
Publication of WO2012124999A2 publication Critical patent/WO2012124999A2/ko
Publication of WO2012124999A3 publication Critical patent/WO2012124999A3/ko

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00—Digital computers in general; Data processing equipment in general
    • G06F15/16—Combinations of two or more digital computers each having at least an arithmetic unit, a program unit and a register, e.g. for a simultaneous processing of several programs
    • G06F15/163—Interprocessor communication
    • G06F15/167—Interprocessor communication using a common memory, e.g. mailbox
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/568—Storing data temporarily at an intermediate stage, e.g. caching
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/50—Service provisioning or reconfiguring
    • 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/02—Standardisation; Integration
    • H04L41/0233—Object-oriented techniques, for representation of network management data, e.g. common object request broker architecture [CORBA]
    • 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/052—Network management architectures or arrangements using standardised network management architectures, e.g. telecommunication management network [TMN] or unified network management architecture [UNMA]

Definitions

  • the present specification relates to a resource providing method, a terminal employing the same, a resource obtaining method, and a server employing the same.
  • a representative technology for portable terminal management may include a device management (DM) technology of the Open Mobile Alliance (OMA).
  • the DM manages the terminal by opening a bidirectional session between the DM server and the DM client, and sending and receiving DM commands through the session.
  • the DM client may start a session through the package 1 to the DM server. If the DM server determines that the terminal needs management, the DM client sends a DM notification called Package 0 to the DM client. You can also request a session.
  • the DM client receives a DM notification from the DM server, the DM client may send Package 1 to the DM server to start a DM session.
  • Transport-binding supported by the DM protocol currently includes HTTP-binding, OBEX-binding, WSP-binding, and the like.
  • the transport binding protocol is a type of forwarder used to transfer the semantic of the DM protocol between the DM client and the DM server.
  • the HTTP-binding is a method of delivering the DM protocol using the HTTP protocol. .
  • REST-binding has been introduced to deliver the DM protocol, and combining the DM protocol with REST-binding is also called RESTful DM. To understand RESTful DM, you need to know about the REST architecture and what RESTful means.
  • REST Representational State Transfer
  • client-server structure such as client-server structure, session / cookie, stateless, and cache.
  • Features include Cacheable, Layered-System, and Uniform Interface.
  • the software or protocol structure that satisfies these characteristics is described as following the REST principle, or abbreviated as RESTful. In other words, a system, protocol, or software that satisfies the five characteristics listed above is called RESTful.
  • RESTful systems have a number of advantages, including high scalability, generality of interfaces, independent deployment of resources, and layered systems.
  • One intermediary resource is one.
  • RESTful DM is completely different with DM HTTP-Binding, and it is strongly combined with HTTP to transport DM Protocol. (transition of DM Commands to HTTP Commands), conforming to REST principles, and enjoying the benefits of being RESTful.
  • FIG. 1 is a simplified conceptual diagram for a RESTful DM.
  • RESTful DM uses HTTP commands to communicate the DM protocol between the DM server and DM client.
  • the DM client uses the HTTP GET command to specify specific resources (here: DM tree ( Send DM Get command to structure and leaf node data of './scomo' of Tree).
  • the DM server notifies the DM client that the request has been processed correctly through the HTTP status code '200 OK' and sends the requested data.
  • the JSON JavaScript Object Notation
  • FIG. 1 may be different from the specification of RESTful DM in detail.
  • RESTful DM can take advantage of the resource caching mechanism used by HTTP without any modifications to the DM protocol, which can result in low latency and reduced network traffic between the HTTP server and the HTTP client. have.
  • HTTP caching the HTTP client caches the resources received from the HTTP server locally, and when requested again with the same URI, it will be sent back from the HPPT server only if the resources have changed. To do this, you need a way to determine if the resource has changed, and use a cache validator to determine if the resource has changed.
  • HTTP typically uses ETag and Last-Modified as cache validators.
  • An ETag is a type of identifier that an HTTP server assigns to a specific version of a resource.
  • an HTTP server receives a request for a URI, it sends the resource represented by the URI and the ETag value assigned to that resource.
  • the HTTP server changes the ETag value when the resource changes (when the resource version changes), which compares the ETag value sent by the HTTP client with its own ETag value when the HTTP client makes a request for the same URI. By doing this, the HTTP client is caching the latest version of the resources it is caching. If the HTTP client has the latest version of the resource, the HTTP server does not need to send the resource again.
  • an HTTP client requests an image file resource called "a.jpg” through a URI called "http://www.server.com/a.jpg.”
  • the HTTP server sends an HTTP header called ETag with an image file that is the requested resource.
  • This ETag header indicates the ETag value assigned to the image file resource of the current version.
  • the HTTP client receives the response and caches the image file resource locally. It also stores the ETag value.
  • an HTTP client sends a request for the same URI it includes an ETag that it stores, using an HTTP header called 'If-None-Match'.
  • the HTTP server receives this request and compares it with the ETag value for the current version of the resource represented by the URI. If the two values are the same, it tells the HTTP client that the resource has not been modified.
  • the HTTP client receives this response from the server and verifies that the resource it is storing is the latest version, and uses the latest version resource without sending it back from the server.
  • Last-Modified is an HTTP cache validator other than ETag.
  • Table 2 below outlines HTTP caching using Last-Modified.
  • Last-Modified means the time the resource was last changed.
  • the HTTP server sends a resource to the HTTP client
  • the HTTP server's Last-Modified header includes the time when the resource was last changed.
  • the HTTP client stores the resource and Last-Modified value locally.
  • the HTTP client sends the last modified time of the received resource in the If-Modified-Since header.
  • the HTTP Server will update the resource change time each time the resource changes, and if the request for the same URI contains an If-Modified-Since header, then compare the time with the time it manages, and then change the resource. If you think it is, you will be retransmitted.
  • HTTP caching which uses ETags as cache verifiers, compares the HTTP server's ETag with the HTTP client's ETag to ensure that the resources stored by the HTTP client are up to date.
  • ETags One thing to keep in mind when comparing ETags is that you must compare only the Etags for the same URI. That is, the ETag values for different URIs may be the same or different, but such comparisons have no meaning. The same applies to the Last-Modified cache verifier, and only a comparison of Last-Modified against the same URI is meaningful.
  • HTTP caching can also be applied to RESTful DM, which is one of the advantages of certain protocols following the REST architecture.
  • Table 3 below shows the application of HTTP caching to RESTful DM and uses ETag as a cache validator.
  • the DM server sends a request for a specific resource to the DM client.
  • the DM client sends a Download subtree resource with a status code of '200 OK', which also sends an ETag value.
  • the DM server sends a request for the same URI, it sends an ETag value for the cached resource through an HTTP header called If-None-Match.
  • the DM client receives the request, compares the ETag value, and determines that the Download subtree resource has changed. In Table 3, the ETags match, so the DM Client sends a status code of '304 Not Modified'.
  • RESTful DM which applies the REST architecture to the DM protocol, has a big advantage of resource caching. This is possible by applying HTTP caching of the HTTP protocol, an example of which has been described with reference to Table 3 above.
  • Table 4 below shows another example of caching DM resources using HTTP caching in RESTful DM.
  • DM server includes If-None-Match HTTP header and delivers ETag value for the version of resource it caches.
  • the DM client compares the ETag values and, if they are the same, sends a "303 Not Modified" status code to indicate that the resource the DM server has is up to date.
  • the DM server uses cached resources because its resources are up-to-date.
  • the second response from the DM client that sends the ‘SCOMO / Download / Email’ subtree resource is not needed. This is because the second requested resource is a subset of the first requested resource. That is, since the first resource requested by the DM client includes the second resource, and there was no resource update during the request, the DM server can be regarded as having the latest version locally for the second requested resource. However, since the HTTP caching mechanism determines that a request for a different URI is a request for a separate resource, the two resources requested by the DM server are classified as separate resources and thus the caching mechanism cannot be applied.
  • Resource caching in RESTful DM using HTTP caching is inefficient because this inclusion relationship is not taken into account.
  • the DM client transmits resources that do not need to be transmitted in the second response, which wastes network bandwidth, increases response time, and increases power consumption of the DM client.
  • the present invention relates to a method for caching a DM tree, which is a main DM resource exchanged between a DM server and a DM client. Entailed).
  • the present invention also provides a method for caching DM resources regardless of the type of cache verifier used by the cache mechanism.
  • it is to provide a DM resource caching method irrespective of the lower transport binding (REST-binding, HTTP-binding, OBEX-binding, etc.) used in the DM protocol.
  • a method of acquiring a resource from a device management client by a device management server may include determining whether a first type of cache validator exists for the first resource; Wherein the first type of cache verifier is used directly for the first resource, and if there is no first type of cache verifier for the first resource, the second type of cache for the first resource Determining if a validator exists; Wherein the second type of cache verifier is used for a second resource that includes the first resource, and if there is a second type of cache verifier for the first resource, an identifier for the first resource And sending a request for the first resource to the device management client by using the identifier for the second resource and the cache verifier for the second resource.
  • the first node associated with the first resource and the second node associated with the second resource are included in the device management tree.
  • determining whether a second type of cache verifier for the first resource exists includes: retrieving a second type of cache verifier for the first resource at a current node; Setting a parent node of the current node as the current node; And repeating the searching and setting until the first type of cache verifier for the first resource is found, wherein the current node is initially a parent node of the first node. It characterized in that it is set to.
  • the determining of whether there is a second type of cache verifier for the first resource may include: one for the first resource from a parent node of the first node to a root node of the device management tree. And searching for the second type of cache verifier.
  • determining whether a second type of cache verifier for the first resource exists includes: generating a first resource for the first resource from one or more second type of cache verifiers for the first resource. Selecting two types of cache verifiers.
  • the first resource and the second resource are each characterized by being a network data object or a service that can be identified by a corresponding identifier.
  • the method for acquiring a resource of the device management server may include an identifier for the first resource and a cache for the first resource when a first type of cache verifier exists for the first resource. And using the verifier to transmit a request for the first resource to the device management client.
  • the method for acquiring a resource of the device management server may include using the identifier for the first resource when the second type of cache verifier does not exist for the first resource. And transmitting a request for the first resource.
  • the method for providing a resource to a device management server by a device management client includes: receiving a request for a first resource from the device management server; Wherein the request comprises a first or second type of cache validator for the first resource, the first type of cache validator being used directly for the first resource, A second type of cache verifier is used for a second resource that includes the first resource, and if the request includes the first type of cache verifier, then the first type of cache verifier is assigned to the first resource.
  • transmitting the message may optionally include: verifying the first type of cache for the first resource stored in the device management client. If there is a self, the step of transmitting the message using the first type of cache verifier.
  • the method for providing a resource of the device management client may include: the first type of cache validator is not valid for the first resource or the second type of cache validator is valid for the second resource. If not, further comprising the step of transmitting the first resource to the device management server.
  • the transmitting of the first resource may include: when the first type of cache validator exists for the first resource stored in the device management client, the first type of cache validator; And transmitting the resource together.
  • the first node associated with the first resource and the second node associated with the second resource may be included in a device management tree.
  • the first resource and the second resource are each characterized by being a network data object or a service that can be identified by a corresponding identifier.
  • the DM server when the DM server requests a non-cached resource, by using the cache verifier of other resources including the requested resource, transmission of the DM resource can be reduced, thereby saving network bandwidth and power consumption.
  • the present invention can be applied regardless of a specific cache validator, for example, a cache validator such as ETag, Last-Modified, and there is an advantage that can be combined with anything below transport binding.
  • FIG. 1 is a simplified conceptual diagram for a RESTful DM.
  • FIG. 2 is a diagram illustrating a device management architecture according to embodiments of the present invention.
  • FIG. 3 is a flowchart illustrating a process of making a request using an inclusive cache verifier when making a resource request in a RESTful DM according to an embodiment of the present invention.
  • FIG. 4 is a flowchart illustrating a process of receiving and processing a request for a DM resource by a DM client according to an embodiment of the present invention.
  • 5A and 5B are conceptual views illustrating changes of a DM tree according to an embodiment of the present invention.
  • FIG. 6 is a flowchart illustrating a process of updating a cache validator of a leaf node according to an embodiment of the present invention.
  • FIG. 7 is a flowchart illustrating a process of updating a cache verifier of an inner node according to an embodiment of the present invention.
  • FIG. 9 is a flowchart illustrating a process in which a DM server requests a resource from a DM client according to light resource caching according to an embodiment of the present invention.
  • FIG. 10 is a flowchart illustrating a process in which a DM client responds to a DM server according to light resource caching according to an embodiment of the present invention.
  • FIG. 11 is a flowchart illustrating a process in which the DM client 110 sends a response to PKG # 1 according to an embodiment of the present invention.
  • FIG. 12 is a block diagram of the terminal 200 and the server 300 according to an embodiment of the present invention.
  • OMA-TS-DM_HTTPBinding-V1_3 http://www.openmobilealliance.org
  • [DM1.3] of TS-DM_Protocol-V1_3 http://www.openmobilealliance.org
  • Device Management HTTP Binding [DM-HTTP-Binding] is incorporated herein by reference.
  • a resource may generally be a collection of electronic documents, images, servers, and other resources.
  • DM resource refers to a kind of resource exchanged between DM server and DM client for device management operation.
  • DM resources refer to network data objects or services, each of which can be identified by a corresponding identifier.
  • a typical example of a DM resource is a DM tree (or part of a DM tree).
  • DM resources are uniquely identified by a URI, for which absolute URI addressing may be used.
  • Caching is a generic term for a technique for storing a copy of a resource (eg, a web cache) between servers and clients.
  • the client saves the previous response from the server and reuses the copy when the same resource is requested.
  • DM resource R1 of URI1 may include DM resource R2 of other URI2.
  • Cache Validator is a component that can be used for cache validation.
  • Cache verification is a process of determining whether a resource cached in a requestor is fresh. The term 'fresh' means that the resource has not changed since it was sent to the requestor.
  • Typical examples of cache validators used in web caches are the Etag and Last-Modified fields.
  • the cached resource contains the resource to be requested, the cache is an Inclusive Cache.
  • resources may be in a containment relationship and resource R1 may include another resource R2.
  • R1 may include another resource R2.
  • the cached resource is directly for the requested resource, the cache is a direct cache. This term is used to distinguish the direct cache from the inclusive cache. In the web cache, all caches are direct caches.
  • the Inclusive Cache Validator is a cache validator used to validate an inclusive cache.
  • the Etag and Last-Modified fields may be an inclusive cache verifier.
  • Direct Cache Validator is a cache validator that is used to validate the direct cache.
  • the Etag and Last-Modified fields may be direct cache verifiers.
  • FIG. 2 is a diagram illustrating a device management architecture according to embodiments of the present disclosure.
  • DM Device management
  • the DM enabler 100 including a DM client 110 and a DM server 120.
  • the DM client 110 is an abstract software component that follows the requirements of the DM client as specified in the Open Mobile Alliance (OMA) Device Management Enabler.
  • OMA Open Mobile Alliance
  • DM server 120 is an abstract software component that follows the requirements of the DM server specified in the OMA Device Management Enabler.
  • the client-server notification DM-1 provides an interface through which the servers 120 can send device management notifications to the clients 110.
  • Client-server notification (DM-1) is an intermediate carrier and is an interface that can operate over many protocols such as WAP push and SIP push.
  • the Device Management Client-Server Protocol (DM-2) is an interface through which servers 120 can send device management commands to clients 110 and clients 110 can send status and alarms to servers 120.
  • Device Management Client-Server Protocol (DM-2) is an intermediate carrier and an interface that provides many standardized bindings, including HTTP and HTTPS. This interface is exposed through a radio-based data transfer protocol (eg, GPRS) to provide over-the-air device management capabilities.
  • GPRS radio-based data transfer protocol
  • DM client 110 may initially be supplied via a file on smart card 210.
  • This file contains a series of DM commands for setting or changing settings at the DM client 110.
  • the DM bootstrap profile (DM-3) via the smart card 210 is a unidirectional interface where no feedback from the DM client 110 is provided. In the next practical opportunity, the DM client 110 connecting to the DM server 120 is the only expected result.
  • the DM client 110 may initially be supplied via a file sent by some push protocol. This file contains DM commands for setting or changing settings on the DM client.
  • the bootstrap profile OTA (DM-4) is a one-way interface from the OTA server 220 to the DM client 110 where no feedback from the DM client 110 is provided. In the next practical opportunity, the DM client 110 connecting to the DM server 120 is the only expected result.
  • the DM client 110 may initially be supplied via the CP enabler 230.
  • the CP bootstrap profile CP-1 is a unidirectional interface from the CP enabler 230 to the DM client 110 where no feedback from the DM client 110 is provided. In the next practical opportunity, the DM client 110 connecting to the DM server 120 is the only expected result.
  • RESTful DM uses the HTTP protocol to transfer DM messages between DM server 120 and DM client 110.
  • Existing DM transport binding using HTTP may be DM HTTP binding [DM-HTTP-Binding], but RESTful DM and DM HTTP binding are very different.
  • RESTful DM replaces DM commands with HTTP methods to represent them in HTTP headers.
  • the DM HTTP binding puts the POST method in the HTTP header, and the DM command goes in the HTTP body, regardless of the actual DM command.
  • the DM Get command is replaced with the HTTP GET method and put in the HTTP header.
  • RESTful DM makes extensive use of the relevant HTTP headers, allowing it to be more tightly coupled with the HTTP protocol and to take advantage of the HTTP protocol. For example, HTTP caching is available in RESTful DM.
  • RESTful DM replaces DM commands with HTTP methods.
  • the HTTP protocol delivers specific methods for resources separated by URIs.
  • the simplest example is ‘GET http://www.server.com/img.jpg’. This is to get the resource specified by the URI "http://www.server.com/img.jpg”.
  • a RESTful DM sends a DM message by sending a URI and a method on the URI, where the DM resource must be consistently represented by the URI. This method is not yet defined in the OMA DM WG, but the present invention uses the method of Table 5, which can be generally considered.
  • the ability to use HTTP caching for a DM's resources is one of the benefits of RESTful DM, but applying HTTP caching to the DM is inefficient. This is because there is no correlation between resources designated as URIs in HTTP, but there is an inclusive relationship between DM resources. That is, the relationship between the resource R1 designated by URI1 and the resource R2 designated by URI2 is established in the DM protocol.
  • Table 6 below shows the inclusion relationship between these DM resources.
  • This table does not show all the containment relationships of DM resources, but shows some examples of include relationships.
  • Direct cache is a cache concept allowed by the existing HTTP protocol. When a request for a resource of URI1 is made, the direct cache has a direct cache for URI1.
  • a cache validator is a directive that provides information about whether a locally cached resource version is up to date.
  • ETag and Last-Modified are widely used as cache validators, and the same type of cache validator can be applied regardless of whether it is a direct cache or an inclusive cache. That is, both ETag and Last-Modified can be applied to both direct cache and inclusive cache, and the operation method is the same.
  • the present invention proposes a method of utilizing an inclusive cache in addition to an existing direct cache when a DM resource is exchanged between a DM server and a DM client. This requires that both the entity requesting the DM resource (typically a DM server) and the entity responding to the request (generally a DM client) change.
  • entity requesting the DM resource typically a DM server
  • entity responding to the request generally a DM client
  • FIG. 3 is a flowchart illustrating a process of making a request using an inclusive cache verifier when making a resource request in a RESTful DM according to an embodiment of the present invention.
  • the entity requesting the DM resource may not necessarily be the DM server, it is assumed that the DM server is a DM server.
  • the DM server 120 determines to request the DM client 110 (DMC) the resource designated by URI1 (S110).
  • the DM server 120 checks whether the DM server 120 has a cached resource before sending a request for URI1 (S120).
  • the cache may be a direct cache or an inclusive cache. Therefore, the cache retrieved in this step may be a large number.
  • the DM server 120 may retrieve the inclusive cache in a variety of ways. For example, the DM server 120 initially sets the parent node of the node corresponding to the requested resource as the current node. The DM server 120 then retrieves an inclusive cache verifier for the resource requested by the current node. The DM server 120 sets the parent node of the current node as the new current node. The DM server 120 repeats the searching of the inclusive cache verifier and the setting of the new current node until the inclusive cache verifier for the requested resource is found for the first time.
  • the DM server 120 retrieves an inclusive cache verifier for the requested resource from the parent node of the node corresponding to the requested resource to the root node of the DM tree.
  • the DM server 120 sends a request without the cache to the DM client 110 (S130).
  • the request includes URI1, the details of which depend on the request. However, since there is no cache, the request does not include cache-related information.
  • the DM server 120 checks whether the cache found in step 120 is a large number (S140).
  • S150 If there are a large number of caches found in operation 120, one of them is selected (S150).
  • Factors that can be considered for selecting a cache include a cache type, a cache generation time, a cache range, and the like.
  • the cache type indicates whether the cache is a direct cache or an inclusive cache. In the case of the direct cache, the validity of the cache is simpler and more efficient than that of the inclusive cache.
  • the cache creation time is that the cache generated later in time has a higher probability of a cache hit.
  • a cache hit is when a cache client (CPU, web browser, operating system) accesses data that is presumed to exist in auxiliary storage, and if the tag is found as an entry that matches the entry of the desired data, it checks the cache. The situation where entries are used instead of data.
  • a cache hit means a situation in which the cache verifier received from the DM server 120 at the DM client 110 is valid.
  • the cache creation time is that the cache generated later in time has a higher probability of a cache hit.
  • a cache miss refers to a situation in which the cache verifier received from the DM server 120 at the DM client 110 is invalid.
  • the DM server 120 checks whether the selected cache is a direct cache or an inclusive cache (S160).
  • the request for DM resources follows the method of HTTP caching. That is, the request for the DM resource includes a URI1 for the requesting resource and a cache verifier (S170).
  • the cache verifier is a cache verifier that is used directly for cached resources for URI1 because it is a direct cache verifier.
  • This step is a case of requesting a DM resource using an inclusive cache verifier.
  • a request including URI1 (the URI of the requested resource), an inclusive cache verifier for the selected cache, and a URI for the selected cache is sent to the DM client (S180).
  • FIG. 4 is a flowchart illustrating a process of receiving and processing a request for a DM resource by a DM client according to an embodiment of the present invention.
  • this process which can be regarded as a response process, the process of processing a response does not necessarily need to be a DM client.
  • the DM client 110 receives a DM resource for URI1 from the DM server 120 (S210).
  • the DM client 110 checks whether the direct message verifier (ETag or Last-Modified) is included in the request message (S220). If the HTTP header contains the If-None-Match field, it means that it includes the cache validator ETag, and if it contains the If-Modified-Since field, it can be determined that the cache validator, Last-Modified, is included. .
  • ETag direct message verifier
  • the DM client 110 may check whether the resource version cached by the DM server 120 is the latest version through the cache verifier (S230). If the cache verifier is an Etag, if the value of the ETag included in the request message and the Etag value of the DM client 110 match, the DM client 110 determines that the cache is valid. Since Last-Modified represents the last modification time, after the last modification time included in the request, the validity can be determined by checking whether the resource has been modified.
  • the DM client 110 checks whether there is an inclusive cache verifier (S250).
  • the inclusive cache verifier can also be delivered via HTTP headers.
  • the header name identifies what kind of cache validator it is, the field names used must be different.
  • a header field called Inclusive-If-None-Match may be used, and in the case of Last-Modified, a header field called Inclusive-If-Modified-Since may be used.
  • Inclusive cache verifiers unlike direct cache verifiers, must include an additional URI in the HTTP header. This URI is an item called a URI for a cache described in operation 180 of FIG.
  • the DM client 110 checks whether the cache for URI1 that the DM server 120 has locally is valid by using the received inclusive cache verifier (S260).
  • Inclusive cache verifier further includes one URI as described in operation 250. This URI indicates which resource the inclusive cache is actually a cache for and assumes that this URI is IC_URI.
  • the resource indicated by IC_URI includes the resource indicated by URI1 (inclusive relationship).
  • the DM client 110 may check whether the resource for the IC_URI has changed through the inclusive cache verifier of the IC_URI. If the IC_URI resource has not changed, it means that the resource for URI1 has not changed.
  • the DM client 110 stores tracking information about the changed DM resource, and checks whether each change is a change of a resource of IC_URI or a change of a resource of URI1.
  • the DM client 110 sends the entire resource (full version of the resource) to the DM server 120 (S270).
  • the cache verifier for URI1 the transmitting resource, is transmitted.
  • the transmitted cache verifier can be used by the DM server 120 later when requesting the same resource.
  • the DM client 110 does not need to retransmit the resource to the DM server 120.
  • the DM server 120 since the DM server 120 does not have a direct cache verifier for URI1, the DM server 120 transmits a cache verifier for URI1 (S280).
  • This direct cache verifier can be used when the DM server 120 later requests the same resource. This is because the direct cache is simpler to process than the inclusive cache.
  • HTTP HyperText Transfer Protocol
  • a '304 Not Modified' status code is used to indicate a cache hit, and the same method is applied to a RESTful DM so that the DM client 110 can notify the DM server 120 of the cache hit.
  • the DM client 110 transmits the entire resource for the requested resource to the DM server 120. However, if only part of the total requested resource has changed, sending the full resource (full version) is inefficient. At this time, only the changed part can be sent, not the entire resource. This is called a delta response.
  • 5A and 5B are conceptual views illustrating changes of a DM tree according to an embodiment of the present invention.
  • the DM server 120 performs a Get on the root of the DM tree shown in FIG. 5A, and stores the cache verifier CV1 for the entire DM tree and the root (/) locally. In this case, it is assumed that the DM tree is updated as shown in FIG. When updated, the cache validator for root is also updated. Assume the new cache validator for root is CV2. Now, when DM server 120 does a Get for root (/) with CV1, DM client 110 sends the entire resource because CV1 is different from CV2, the cache verifier for the root it is storing. It becomes. This is the part described with reference to FIG. 4.
  • Delta responses may include updating existing nodes, adding new nodes, deleting existing nodes, and so forth.
  • Table 7 shows an example of a DM resource caching method using an inclusive cache in a RESTful DM.
  • the details of each are as follows.
  • the DM client 110 receives the request and transmits the corresponding resource to the DM server 120 (Response 1).
  • the resource is transmitted via an HTTP body, and the DM client 110 further sends a cache verifier.
  • ETag is used as the cache validator.
  • the DM tree stores node values in leaf nodes, and also allows access control lists (ACLs), formats, names, sizes, titles, TStamps, types,
  • ACLs access control lists
  • VerNo The node property of VerNo is used to store data related to the node. All of these data are cacheable resources, but among these, node names and node values are particularly important resources.
  • only one cache validator is assigned and managed per node.
  • Only one cache validator is assigned to a node, and one node has only one cache validator.
  • the cache validator assigned to a leaf node covers the node URI and node value of the leaf node. In other words, when the node URI and node value of the leaf node are updated, the cache validator of the leaf node is updated.
  • the cache verifier assigned to the inner node covers the node URI of the inner node and the node URI of all descendant nodes (mode nodes except the inner node in the sub-tree rooted on the inner node) and the node values of all descendant leaf nodes. If the node URI of the inner node, the node URI of all descendant nodes, and the node value of all descendant leaf nodes are updated, the cache verifier for the inner node must be updated.
  • a node URI is constructed by concatenating the node name and delimiter of all nodes from the root node to that node, so changing the node name changes the node URI of that node and its descendants. Bring.
  • the node URI change is confirmed with the node name change.
  • FIG. 6 is a flowchart illustrating a process of updating a cache validator of a leaf node according to an embodiment of the present invention.
  • the DM client 110 receives a DM command for the leaf node A from the DM server 120 (S310).
  • the DM client 110 checks whether the DM command is a command for changing a name or a value of a leaf node as a command for changing an existing node (S320).
  • the DM client 110 checks whether the DM command is a command for newly adding node A (S330).
  • the DM client 110 checks whether the DM command is a command for deleting the existing node A (S340).
  • the DM client 110 does not update the cache verifier (S350).
  • DM client 110 is responsible for all nodes from node A to the root node (all nodes above the shortest path from node A to the root node). Update the cache validator (S360).
  • DM client 110 validates the cache of all nodes starting from A's parent node to the root node (all nodes on the shortest path from A's parent node to the root node). Update the ruler (S270).
  • FIG. 7 is a flowchart illustrating a process of updating a cache verifier of an inner node according to an embodiment of the present invention.
  • the DM client 110 receives a DM command for the inner node A from the DM server 120 (S410).
  • the DM client 110 checks whether the DM command is a command for changing the node name of A (S420).
  • the DM client 110 checks whether the DM command is a command for newly adding node A (S430).
  • the DM client 110 checks whether the DM command is a command for deleting node A (S440).
  • the DM client 110 does not update the cache verifier (S450).
  • the DM client 110 updates the cache verifier on all nodes from node A to the root node (all nodes on the shortest path from A to the root node). do.
  • the cache verifier of all nodes in the sub-tree having A as the root node is updated (S460). At this time, since the cache validator of node A has already been updated, it is not duplicated.
  • DM client 110 checks the cache of all nodes starting from A's parent node to the root node (all nodes on the shortest path from A's parent node to the root node). Update the ruler (S470).
  • the terminal manages a total of seven cache validators, one for each node. This can significantly reduce the number of cache validators than having one cache validator per URI.
  • the DM client 110 updates the cache validators of node1-1, node1, and root node. If the node2-1-1 node is deleted, the DM client 110 updates the cache validators of node2-1, node2, and root node. If the node2-2 node is newly added, the DM client 110 updates the cache validators of node2-2, node2, and root node. If the node2 node name is changed, the DM client 110 updates the cache validators of node2, root, node2-1, node2-2, and node2-1-1.
  • Resource request using light resource caching is similar to the resource request method described with reference to FIG. 3.
  • the resource request scheme of FIG. 3 uses a URI-based cache verifier, whereas lightweight resource caching has a node-based cache verifier and differs because the cache verifier covers only node URIs and node values.
  • FIG. 9 is a flowchart illustrating a process in which a DM server requests a resource from a DM client according to light resource caching according to an embodiment of the present invention.
  • the DM server 120 determines to request the DM client 110 for the resource designated by URI1 (S510).
  • URI1 refers to a specific node A.
  • the “./a/b” URI also refers to the “./a/b” node.
  • the DM server 120 searches for a local cache including a resource to be requested (S530). This is true if any of the nodes from node A to the root node has a cache.
  • the DM server 120 checks whether the number of caches found in step 530 is several (S540).
  • the DM server 120 selects one cache (S550). For example, the DM server 120 may select one cache from among several caches based on the cache generation time and the cache range.
  • the cache generation time is because the cache generated later in time is more likely to be a cache hit, the cache range is a higher cache hit probability, and the validity judgment is simpler. That is, in the case of a cache having a wide range, the probability of updating the corresponding resource is high, and the probability of cache miss is increased.
  • the DM server 120 uses the cache to request a resource.
  • the request message is sent, including the requesting resource URI1, the cached node's URI, and the cache verifier.
  • the “./node2-1?list StructData” and “. / node2 ”
  • CV1 is the cache validator for “./node2”. If the node indicated by the requesting resource URI1 matches the cached node, the cached node URI may be omitted, and the DM server 120 requests URI1 using only URI1 and a cache verifier.
  • the DM server 120 If it does not have a local cache containing the resource to be requested, the DM server 120 requests URI1 without the cache (S570).
  • FIG. 10 is a flowchart illustrating a process in which a DM client responds to a DM server according to light resource caching according to an embodiment of the present invention.
  • the DM client 110 receives a request for URI1 (S610).
  • URI1 refers to node A.
  • the “./a/b” URI also refers to the “./a/b” node.
  • the DM client 110 determines whether it is a resource request using a cache. If the cache verifier is included, it is a resource request using the cache (S620).
  • the DM client 110 checks whether the requested resource is a cacheable resource (S630). If the request is for a node name and node value, it is a request for a cacheable resource.
  • the DM client 110 sends the requested resource to the DM server 120 (S640). Since it is not a cacheable resource, there is no need to send a cache verifier.
  • the DM client 110 sends the requested resource to the DM server 120 together with the cache verifier for the node A (S650).
  • the request includes (URI1, cached node URI, CV1).
  • the DM client 110 checks whether it is a cache hit (S660). If the cache verifier stored in the DM client 110 and CV1 match the cached node URI, the DM client 110 may determine that the cache is a hit. If it is not a cache hit, the DM client 110 sends the requested resource to the DM server 120 together with the cache verifier for the node A (S650).
  • step 660 in case of a cache hit, the DM client 110 checks whether the cache is for node A (S670). If the node A URI matches the cached node URI included in the request, then it is a cache for node A.
  • step 670 if the server has a cache verifier for the node A, the DM client 110 transmits “Not Modified” to the DM server 120 (S680).
  • the DM client 110 may verify the cache verifier for the node A that the DM client 110 stores. ) Is transmitted together (S690).
  • the DM server 120 processes the response received from the DM client 110.
  • the DM client 110 responds to steps 640, 650, 680, and 690.
  • the DM server 120 uses the resource received from the DM client 110 without any further processing.
  • the DM server 120 caches the received resource locally.
  • the DM server 120 uses the locally cached resource.
  • step 690 since the locally cached resource is the latest version, the DM server 120 uses the cached resource, and the received cache verifier stores the cache verifier for Node A.
  • Lightweight resource caching allows you to have only one cache validator per node, so that the cache validator covers only the node name and node value.
  • the following describes how only a few selected nodes have cache verifiers. According to this method, since no cache verifier is provided for every node, the overhead of the terminal can be reduced.
  • a cache verifier node refers to a node to which a cache verifier can be assigned. That is, only nodes designated as CV nodes can have cache validators. As such, a node that can be designated as a CV node may be a MO root node. For small MOs such as DevInfo and DevDetail, it is sufficient to make only the MO root node a CV node. However, MOs such as SCOMO are large, and in addition to the MO root, additionally, “./SCOMO/Download”, “./SCOMO/Inventory/Delivered”, and “./SCOMO/Inventory/Deployed” can be specified as CV nodes. Determine which nodes to allocate as CV nodes individually for each MO.
  • DevInfo has a minimum of six nodes, including the MO root, so if all nodes have a cache validator, a total of six were required, but if you specify only the MO root on a CV node, you can reduce the cache validator to one.
  • the cache verifier update is basically the same as the update method described with reference to FIGS. 6 and 7.
  • the cache verifier is updated only for the CV node. This is because non-CV nodes cannot have cache validators.
  • the cache verifier update is performed only for the CV node in steps 360 and 370.
  • the verifier update is performed only for the CV node in steps 460 and 470.
  • the resource request method is the same as the resource request method described with reference to FIG. 9. This is because a node that is not designated as a CV node does not have a cache validator, and thus only appears to be not cached in step 530.
  • the response method of the DM client 110 is also basically the same as the response method described with reference to FIG. 10. However, in step 650 and step 690, the cache verifier is not always sent to the node A, and the cache verifier is sent only when the node A is the CV node. Again, non-CV nodes cannot have cache validators.
  • the DM server 120 When the DM server 120 needs a terminal management of the DM client 110, the DM server 120 sends a DM notification to the DM client 110.
  • the DM client 110 receiving the DM notification establishes a DM session with the DM server 120 to receive device management from the DM server 120.
  • the DM server 120 may insert the MO index into the DM notification and receive the MO from 'PKG # 1'.
  • the MO index is a 2-byte number and, like the MOID, is used as an identifier for a specific MO. The reason for using the MO index is that it is shorter than the MOID based on plain text.
  • the MO index in the DM notification the corresponding MO data can be received in the 'PKG # 1', thereby improving responsiveness.
  • caching can be applied as follows.
  • the DM server 120 checks whether the MO root of the MO to request is designated as the CV node. Applicable when the MO root is a CV node. If the DM server 120 has a cache verifier for the MO root node, the DM server 120 inserts (MO index, cache verifier for the MO root) into the DM notification and transmits it to the DM client 110. For example, if the MO index of DevInfo MO is 100, the DevInfo MO root URI is “./DevInfo”, and the cache verifier of “./DevInfo” that the DM server 120 has is CV1, the DM server 120 Including DM (100, CV1) in the DM notification. The DM client 110 sends a response to 'PKG # 1'.
  • FIG. 11 is a flowchart illustrating a process in which the DM client 110 sends a response to PKG # 1 according to an embodiment of the present invention.
  • the DM client 110 receives a DM notification from the DM server 120 (S710). It is assumed that the DM notification contains a cache validator for the MO index and the MO root. If there is no MO index or there is an MO index but no cache verifier, then the definition of DM 1.3 is used.
  • the DM client 110 searches for a MO root node referred to as an MO index in the DM tree (S720). First, a MOID matching the MO index is obtained, and all nodes having the MOID are searched. The found node is the MO root node.
  • operation 720 it is determined whether there are a plurality of MO root nodes. If there are a plurality of MO root nodes found, it may proceed in either A type or B type. Method A goes to step 780 and method B goes to step 790.
  • the found MO root node is a CV node. This is because the cache verifier is sent only when the MO root node of the MO requested by the DM server 120 is a CV node.
  • the DM client 110 checks whether the cache verifier of the MO root node that is found and the cache verifier that the DM server 120 has sent match (S740). If so, the DM client 110 determines that it is a cache hit.
  • the DM client 110 transmits the MO data requested by the DM server 120 (S750).
  • the DM client 110 further sends a cache verifier for the MO root node to the DM server 120.
  • one of DM A type and B type is selected.
  • the DM client 110 has a cache verifier of the MO root node (the cache verifier is present only if the MO lot node is a CV node) and the cache sent by the DM server 120. Search whether there is a MO route matching the verifier (S790).
  • the DM client 110 sends a message “Multiple Found, no cache hit” to the DM server 120, and the MO data is transmitted. Do not (S792). This is because it is impossible to know which of the plurality of MO data to send.
  • DM client 110 sends MO data for the MO root node that has a cache verifier that matches the cache verifier sent by DM server 120 to DM server 120. Since a large number has been found, the DM client 110 additionally transmits the MO root node URI to inform the DM server 120 of which MO root node (S794).
  • RESTful DM is a kind of transport binding that transfers a DM message between the DM server 120 and the DM client 110, and is not a core function of the DM protocol. This is because the HTTP transport binding and the OBEX binding can be used as the DM transport binding. In this case, the caching of the RESTful DM described above cannot be used.
  • DM resource caching at the DM protocol level is a caching method independent of transport binding, and has an advantage of using DM resource caching regardless of transport binding.
  • Table 8 shows a method of caching DM resources using a direct cache at the DM protocol level.
  • Table 8 assumes that the DM server 120 requests a DM resource.
  • the DM server 120 requests the DM client 110 for the DM resource "./antivirus_data/version" (Request 1).
  • the DM client 110 Since the cache verifier is not included in the request message, the DM client 110 makes a full response.
  • the DM client 110 includes the data about the request in the ⁇ Item> element and transmits the data to the DM server 120.
  • ETag is used as cache validator for “./antivirus_data/version” and ⁇ ETag> element is used to deliver Etag value.
  • the use of the ⁇ ETag> element is an example, and other elements may be used (Response 1).
  • the DMS re-requests the same DM resource "./antivirus_data/version".
  • the Etag value received from the DM client 110 is transmitted together, and for this purpose, the ⁇ IfNoneMatch> element is used (Request 2).
  • the DM client 110 checks the cache validity of whether "./antivirus_data/version" has been changed from the cache verifier for "./antivirus_data/version”. If the DM client 110 determines that the cache is valid, the DM client 110 transmits ⁇ NotModified> to notify the DM server 120 of the cache hit (Response 2).
  • Table 9 shows how to cache DM resources using an inclusive cache at the DM protocol level.
  • Table 9 assumes that the DM server 120 requests a DM resource.
  • the DM client 110 Since the cache verifier is not included in the request message, the DM client 110 makes a full response.
  • the DM server 120 sends two additional pieces of information to take advantage of the inclusive cache.
  • One is the Inclusive Cache Validator, which is passed using the ⁇ IfNoneMatch> element.
  • the other is an Inclusive Cache URI that indicates which resource the Inclusive Cache is actually a cache for and is passed through ⁇ InclusiveCacheURI> (Request 2).
  • FIG. 12 is a block diagram of the terminal 200 and the server 300 according to an embodiment of the present invention.
  • the terminal 200 includes a storage unit 210, a controller 220, and a transceiver 230.
  • the storage means 210 stores a method according to the embodiment shown in Figs.
  • the controller 220 controls the storage means 210 and the transceiver 230. Specifically, the controller 220 executes the methods stored in the storage means 230, respectively.
  • the controller 220 transmits the above-described signals through the transceiver 210.
  • the server 300 includes a storage unit 310, a controller 320, and a transceiver 330.
  • the storage means 310 stores the method according to the embodiment shown in Figures 1 to 12.
  • the controller 320 controls the storage means 310 and the transceiver 330. Specifically, the controller 320 executes the methods stored in the storage means 310, respectively.
  • the controller 320 transmits the aforementioned signals through the transceiver 330.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Transfer Between Computers (AREA)
  • Computer And Data Communications (AREA)

Abstract

DM 서버와 DM 클라이언트간에 주고 받는 주요 DM 리소스인 DM 트리를 캐시하는 방법에 관한 것으로, DM 리소스간의 포함 관계를 고려하여 DM 리소스를 캐시하는 방법. 이를 위해, 본 명세서에 개시된 일 실시 예에 따른 장치관리 서버가 장치관리 클라이언트로부터 리소스를 획득하는 방법은, 제1 리소스에 대한 제1 타입의 캐시 검증자(cache validator)가 존재하는지 판단하는 단계; 여기에서 상기 제1 타입의 캐시 검증자는 상기 제1 리소스를 위해 직접적으로 사용되고, 상기 제1 리소스에 대한 제1 타입의 캐시 검증자가 존재하지 않는 경우에, 상기 제1 리소스에 대한 제2 타입의 캐시 검증자가 존재하는지 판단하는 단계; 여기에서 상기 제2 타입의 캐시 검증자는 상기 제1 리소스를 포함하는 제2 리소스를 위해 사용되고, 상기 제1 리소스에 대한 상기 제2 타입의 캐시 검증자가 존재하는 경우에, 상기 제1 리소스에 대한 식별자, 상기 제2 리소스에 대한 식별자 및 상기 제2 리소스에 대한 캐시 검증자를 이용하여 상기 제1 리소스에 대한 요청을 상기 장치관리 클라이언트에 송신하는 단계를 포함하는 것을 특징으로 한다.

Description

단말의 리소스 제공 방법 및 서버의 리소스 획득 방법
본 명세서는 리소스 제공 방법과 이를 채용하는 단말, 리소스 획득 방법과 이를 채용하는 서버에 관한 것이다.
휴대용 단말 관리를 위한 대표적인 기술로 OMA(Open Mobile Alliance)의 장치 관리(DM; Device Management)기술을 들 수 있다. DM은 DM 서버와 DM 클라이언트 사이에 양방향 세션을 열고, 이 세션을 통해서 DM 명령들(Commands)을 주고 받음으로써 단말 관리를 하게 된다. 이러한 DM 세션을 열기 위해서 DM 클라이언트가 DM 서버에게 Package 1을 통해 세션을 시작할 수 있고, 반대로 DM 서버가 단말 관리가 필요하다고 판단할 경우, Package 0이라 불리는 DM 알림(Notification)을 보내서 DM 클라이언트에게 DM 세션을 요청할 수도 있다. DM 클라이언트는 DM 서버로부터 DM 알림(Notification)을 받은 경우, DM 서버에게 Package 1을 보내 DM 세션을 시작할 수 있다.
DM 프로토콜이 지원하는 트랜스포트-바인딩(transport-binding)은 현재 HTTP-바인딩(HTTP-binding), OBEX-바인딩(OBEX-binding), WSP-바인딩(WSP-binding) 등이 존재한다. 트랜스포트-바인딩(transport binding) 프로토콜은 DM 프로토콜의 내용(semantic)을 DM 클라이언트와 DM 서버 간에 전달하기 위해 사용하는 일종의 전달자로써, HTTP-바인딩은 DM 프로토콜을 HTTP 프로토콜을 이용해서 전달하는 방식을 말한다. 최근에 DM 프로토콜을 전달하기 위해 REST-바인딩(REST-binding)이 거론되고 있는데, DM 프로토콜을 REST-바인딩과 결합시키는 것을 RESTful DM이라고도 한다. RESTful DM을 이해하기 위해서는 REST 아키텍처(Architecture)와 RESTful의 의미에 대해서 알아야 한다. REST(REpresentational State Transfer)는 일종의 소프트웨어 혹은 프로토콜 구조를 설계하기 위한 일종의 디자인 패턴(design pattern)이라고 볼 수 있는데, 클라이언트-서버(Client-Server) 구조, 세션/쿠키를 사용하지 않음(Stateless), 캐시 가능함(Cacheable), 레이어드-시스템(Layered-System), 통합 인터페이스(Uniform Interface)의 특징을 갖는다. 이러한 특징을 만족시키는 소프트웨어 혹은 프로토콜 구조를 REST 원칙을 따른다고 표현하며, 줄여서 RESTful이라고 한다. 즉 앞서 나열한 5개의 특성을 만족시키는 시스템, 프로토콜 혹은 소프트웨어를 RESTful하다고 말한다.
이러한 RESTful 시스템은 다양한 장점을 갖는데, 이러한 장점으로는 높은 확장성(High Scalability), 인터페이스의 일반성(Generality of Interfaces), 리소스의 독립적인 배치(Independent deployment of resources), 레이어드 시스템(Layered system)을 활용한 중개 리소스(intermediary resource)를 들 수 있다. RESTful DM은 DM HTTP-바인딩과 완전히 상이하고(Completely different with DM HTTP-Binding), DM 프로토콜을 전송하기 위해 HTTP와 강하게 결합되고(DM 명령을 HTTP 명령으로 전환)(Strongly combined with HTTP to transport DM Protocol (transition of DM Commands to HTTP Commands)), REST 원칙들을 준수하고(Conforming with REST principles), RESTful이 되는 이익을 향유하는(Enjoying the benefits of being RESTful) 것으로 정의될 수 있다.
도 1은 RESTful DM에 대한 간략한 개념도이다.
RESTful DM에서는 DM 프로토콜을 DM 서버(Server)와 DM 클라이언트(Client)사이에서 전달하기 위해 HTTP 명령(commands)을 사용하는데, DM 클라이언트는 HTTP GET 명령을 이용하여 특정 리소스(resource)(여기서는 DM 트리(Tree)의 ‘./scomo’에 대한 구조(structure) 및 리프 노드 뎅이터(leaf node data))에 DM Get 명령(command)을 보낸다. DM 서버는 DM 클라이언트의 요청이 올바르게 처리되었다는 것을 HTTP 상태 코드(Status code) ‘200 OK’를 통해 알려주고, 요청한 데이터를 보내게 된다. 여기서는 데이터를 보내기 위해 JSON(JavaScript Object Notation) 포맷이 사용되었다. RESTful DM은 아직 표준화가 이루어지지 않은 단계이기 때문에, 도 1은 세부적인 내용에서 RESTful DM의 스펙과 다를 수 있다.
RESTful DM은 별다른 DM 프로토콜 수정 없이 HTTP에서 사용하는 리소스 캐싱 메커니즘(resource caching mechanism)을 이용할 수 있으며, 이러한 HTTP 캐싱은 HTTP 서버와 HTTP 클라이언트 사이에서 응답 속도를 높이고(low latency), 네트워크 트래픽을 줄일 수 있다. HTTP 캐싱을 위해 HTTP 클라이언트는 HTTP 서버로부터 전송 받은 리소스를 로컬에 저장(cache)하고 있다가, 동일 URI로 다시 요청할 때, 해당 리소스가 변경된 경우에만 HPPT 서버로부터 다시 전송 받게 된다. 이를 위해 해당 리소스가 변경되었는지를 판단할 수 있는 방법이 필요하며, 리소스가 변경되었는지 확인하기 위해 캐시 검증자(cache validator)를 사용한다. HTTP에서는 대표적으로 ETag와 Last-Modified를 캐시 검증자(cache validator)로 사용한다.
ETag는 HTTP 서버가 특정 버전의 리소스에게 부여하는 일종의 식별자(identifier)로, HTTP 서버는 URI에 대한 요청을 받았을 때, URI가 나타내는 리소스와 그 리소스에 부여된 ETag 값을 같이 전송해 준다. HTTP 서버는 리소스가 변경되면 (리소스의 버전이 바뀌게 되면), ETag값을 바꾸게 되는데, 이는 HTTP 클라이언트가 동일 URI에 대한 요청을 할 때, HTTP 클라이언트가 보내온 ETag 값과 자신이 가지고 있는 ETag 값을 비교함으로써 HTTP 클라이언트가 캐싱하고 있는 리소스가 최신 버전인지 판단하게 된다. 만약 최신 버전의 리소스를 HTTP 클라이언트가 가지고 있다면, HTTP 서버는 리소스를 다시 전송할 필요가 없다.
다음의 표 1은 ETag를 이용한 HTTP 캐싱을 대략적으로 보여주고 있다.
표 1
Request
Get http://www.server.com/a.jpg HTTP/1.1// other headers here
Response
HTTP/1.1 200 OK…ETag: “686897696a7c876b7e”…// start of body
Request
GET http://www.server.com/a.jpg HTTP/1.1…If-None-Match: “686897696a7c876b7e”…
Response
HTTP/1.1 304 Not Modified
표 1을 참조하면, HTTP 클라이언트는 ‘http://www.server.com/a.jpg’라는 URI를 통해 ‘a.jpg’라는 이미지 파일 리소스를 요청하고 있다. HTTP 서버는 요청된 리소스인 이미지 파일과 함께 ETag라는 HTTP 헤더(header)를 포함시켜 전송한다. 이 ETag 헤더는 현재 버전의 이미지 파일 리소스에 부여된 ETag값을 나타낸다. HTTP 클라이언트는 응답을 받아 이미지 파일 리소스를 로컬에 저장(cache)하며, ETag값 또한 저장한다. HTTP 클라이언트가 동일한 URI에 대한 요청을 보낼 때, 저장하고 있는 ETag를 포함시키는데 이를 위해 ‘If-None-Match’라는 HTTP 헤더를 사용하게 된다. HTTP 서버는 이 요청을 받아 URI가 나타내는 리소스의 현재 버전에 대한 ETag값과 비교하게 되고, 두 값이 동일하면, HTTP 클라이언트에게 리소스가 수정되지 않았음을 알려준다. HTTP 클라이언트는 서버로부터 이러한 응답을 받아 자신이 저장하고 있는 리소스가 최신 버전임을 확인하게 되고 최신 버전 리소스를 서버로부터 다시 전송 받는 일 없이 사용하게 된다.
ETag외에 주로 사용되는 HTTP 캐시 검증자로써 Last-Modified를 들 수가 있다. 다음의 표 2는 Last-Modified를 이용한 HTTP 캐싱을 대략적으로 보여주고 있다.
표 2
Request
Get http://www.server.com/a.jpg HTTP/1.1 // other headers here
Response
HTTP/1.1 200 OK…Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT…// start of body
Request
GET http://www.server.com/a.jpg HTTP/1.1…If-Modified-Since: Tue, 15 Nov 1994 12:45:26 GMT…
Response
HTTP/1.1 304 Not Modified
표 2를 참조하면, Last-Modified의 기본 동작은 ETag와 거의 동일하다. ETag와의 차이점은 ETag가 특정 버전의 리소스에 부여된 임의의 식별자라면, Last-Modified는 리소스가 마지막으로 변경된 시간을 의미한다. 즉 HTTP 서버는 HTTP 클라이언트에게 리소스를 전송할 때, 리소스가 마지막으로 변경된 시간을 HTTP의 Last-Modified 헤더에 포함시켜 보내둔다. HTTP 클라이언트는 리소스와 Last-Modified 값을 로컬에 저장하고 있다가, 동일 URI로 요청을 보낼 때, If-Modified-Since 헤더에 수신한 리소스의 마지막 변경 시간을 포함시켜 보낸다. HTTP Server는 리소스가 변경될 때마다 리소스 변경 시간을 업데이트하게 되고, 동일 URI에 대한 요청이 If-Modified-Since 헤더를 포함하고 있다면, 그 시간과 자신이 관리하고 있는 시간을 비교하여, 리소스가 변경되었다고 생각되면 리소스를 다시 전송하게 된다.
ETag를 캐시 검증자로 이용하는 HTTP 캐싱은 HTTP 서버의 ETag와 HTTP 클라이언트의 ETag를 비교함으로써 HTTP 클라이언트가 저장 (cache)하고 있는 리소스가 최신 버전인지 확인하게 된다. ETag를 비교할 때 한가지 유의할 점은 반드시 동일한 URI에 대한 Etag 만을 비교해야 한다는 점이다 즉 서로 다른 URI의 ETag 값은 같을 수도 다를 수도 있지만, 그러한 비교는 아무런 의미가 없다. 이는 Last-Modified 캐시 검증자에도 동일하게 적용되며, 반드시 같은 URI에 대한 Last-Modified의 비교만이 의미가 있다.
HTTP 캐싱은 RESTful DM에도 적용될 수가 있으며, 이는 특정 프로토콜이 REST 아키텍처를 따르는 장점 중의 하나이다. 다음의 표 3은 RESTful DM에 HTTP 캐싱의 적용을 보여주고 있으며, 캐시 검증자로서 ETag를 사용하고 있다.
표 3
Request
Get http://dev_ip:dm_port/SCOMO/Download?list=StructData HTTP/1.1
Response
HTTP/1.1 200 OKETag: “686897696a7c876b7e”// http body here for the content
Request
GET http://dev_ip:dm_port/SCOMO/Download?list=StructData HTTP/1.1If-None-Match: “686897696a7c876b7e”
Response
HTTP/1.1 304 Not Modified
Last-Modified를 캐시 검증자로 사용한 경우도 적용 방식은 ETag를 사용하는 방식과 거의 유사하다. DM 서버는 DM 클라이언트에게 특정 리소스에 대한 요청을 보내게 된다. 요청하는 리소스는 HTTP에서와 동일하게 URI로 표현되며, 표 3에서는 SCOMO의 Download 서브 트리를 ‘http://dev_ip:dm_port/SCOMO/Download?list=StructData’라는 URI를 통해 요청하고 있다. DM 클라이언트는 ‘200 OK’라는 상태 코드와 함께, Download 서브 트리 리소스를 보내게 되고, 이 때 ETag 값을 같이 전송한다. DM 서버는 동일 URI에 대한 요청을 보낼 때, If-None-Match라는 HTTP 헤더를 통해 캐시된 리소스에 대한 ETag 값을 전송한다. DM 클라이언트는 해당 요청을 받고, ETag값을 비교하여, Download 서브 트리 리소스가 변경되었다고 판단하면, 다시 전송하게 된다. 표 3에서는 ETag가 일치하여, DM Client는 ‘304 Not Modified’라는 상태 코드를 전송하게 된다.
DM 프로토콜에 REST 아키텍처를 적용한 RESTful DM은 리소스 캐싱이라는 큰 장점을 갖게 된다. 이는 HTTP 프로토콜의 HTTP 캐싱을 적용함으로써 가능하며, 그 예는 전술한 표 3을 참조하여 설명하였다.
다음의 표 4는 RESTful DM에서 HTTP 캐싱을 이용해 DM의 리소스를 캐싱한 또 다른 예를 보여준다.
표 4
Request
Get http://dev_ip:dm_port/SCOMO/Download?list=StructData HTTP/1.1If-None-Match: “686897696a7c876b7e”
Response
HTTP/1.1 304 Not Modified
Request
GET http://dev_ip:dm_port/SCOMO/Download?list=StructData HTTP/1.1
Response
HTTP/1.1 200 OKETag: “12122211212wefwef2”// http body here for the content
표 4를 참조하면, DM 서버는 ‘http://dev_ip:dm_port/SCOMO/Download?list=StructData’의 URI를 통해 SCOMO의 Download 서브 트리 리소스에 대한 요청을 보내게 된다. 이때 DM 서버는 If-None-Match HTTP 헤더를 포함시켜, 자신이 캐시하고 있는 버전의 리소스에 대한 ETag값을 전달한다. DM 클라이언트는 ETag값을 비교하여, 동일하면 ‘303 Not Modified’ 상태 코드를 보내, DM 서버가 가지고 있는 리소스가 최신 버전임을 알려준다. DM 서버는 자신이 가지고 있는 리소스가 최신 버전이기 때문에, 캐시된 리소스를 사용한다. DM 서버는 또 다시 ‘http://dev_ip:dm_port/SCOMO/Download/Email?list=StructData’의 URI를 통해 ‘SCOMO/Download/Email’ 서브 트리 리소스를 요청한다. HTTP 캐싱은 서로 다른 URI는 서로 다른 리소스를 나타내기 때문에, 이 요청은 완전히 다른 리소스에 대한 새로운 요청으로 간주된다. 따라서 DM 서버는 ETag없이 요청을 보내게 되고, DM Client는 요청에 대해서 ‘SCOMO/Download/Email’ 서브 트리 리소스를 보내주게 된다.
하지만 표 4에서 보여준 RESTful DM의 리소스 캐싱 시나리오에서 ‘SCOMO/Download/Email’ 서브 트리 리소스를 전송해 주는 DM 클라이언트의 두 번째 응답은 필요하지 않다. 이는 두 번째 요청한 리소스가 처음 요청한 리소스의 서브 셋 (subset) 이기 때문이다. 즉 DM 클라이언트가 요청한 첫 번째 리소스는 두 번째 리소스를 포함하고 있고, 요청이 일어나는 동안 리소스 업데이트가 없었기 때문에, DM 서버는 두 번째 요청한 리소스에 대해서 최신 버전을 로컬에 가지고 있다고 볼 수 있다. 하지만 HTTP 캐싱 메커니즘이 서로 다른 URI에 대한 요청을 별개의 리소스에 대한 요청으로 판단하기 때문에, DM 서버가 요청한 2개의 리소스는 별도의 리소스로 분류되어 캐싱 메커니즘이 적용될 수가 없다. 이는 HTTP와 DM에서 다루는 리소스가 서로 다른 특성을 가지고 있기 때문인데, DM 프로토콜은 DM 트리(Tree)를 리소스로 주로 다르고 있으며, 이 DM 트리는 부모와 자식 노드 관계를 통해, 하나의 리소스가 다른 리소스를 포함하는 경우가 많다. 이러한 DM 리소스 간의 포함 관계를 포함 관계(inclusion relationship)라고 부르며, HTTP 리소스에는 없는 DM 리소스의 독특한 특징이다. 표 4에서는 ETag를 캐시 검증자로 사용하고 있지만, Last-Modifier를 사용하는 경우도 같은 문제가 있다.
HTTP 캐싱을 이용한 RESTful DM의 리소스 캐싱은 이러한 포함 관계를 고려하지 않았기 때문에 비효율적이다. 표 4에서와 같이 DM 클라이언트는 두 번째 응답에서 전송할 필요가 없는 리소스를 전송하기 때문에 네트워크 대역폭(bandwidth)를 낭비하게 되며, 응답 시간이 길어지고, DM 클라이언트의 파워 소모를 증가 시킨다.
본 발명은 DM 서버와 DM 클라이언트간에 주고 받는 주요 DM 리소스인 DM 트리를 캐시하는 방법에 관한 것으로, DM 리소스간의 포함 관계를 고려하여 DM 리소스를 캐시하는 방법(DM 서버와 DM 클라이언트의 동작의 변화가 수반됨)을 제공하기 위한 것이다.
또한, 본 발명은 캐시 메커니즘이 사용하는 캐시 검증자의 종류와 상관없이 DM 리소스를 캐시할 수 있는 방법을 제공한다. 그리고 DM 프로토콜에서 사용하는 하위 트랜스포트 바인딩(REST-바인딩, HTTP-바인딩, OBEX-바인딩 등)과 상관없는 DM 리소스 캐시 방법을 제공하기 위한 것이다.
본 명세서에 개시된 일 실시 예에 따른 장치관리 서버가 장치관리 클라이언트로부터 리소스를 획득하는 방법은, 제1 리소스에 대한 제1 타입의 캐시 검증자(cache validator)가 존재하는지 판단하는 단계; 여기에서 상기 제1 타입의 캐시 검증자는 상기 제1 리소스를 위해 직접적으로 사용되고, 상기 제1 리소스에 대한 제1 타입의 캐시 검증자가 존재하지 않는 경우에, 상기 제1 리소스에 대한 제2 타입의 캐시 검증자가 존재하는지 판단하는 단계; 여기에서 상기 제2 타입의 캐시 검증자는 상기 제1 리소스를 포함하는 제2 리소스를 위해 사용되고, 상기 제1 리소스에 대한 상기 제2 타입의 캐시 검증자가 존재하는 경우에, 상기 제1 리소스에 대한 식별자, 상기 제2 리소스에 대한 식별자 및 상기 제2 리소스에 대한 캐시 검증자를 이용하여 상기 제1 리소스에 대한 요청을 상기 장치관리 클라이언트에 송신하는 단계를 포함하는 것을 특징으로 한다.
일 실시 예에 있어서, 상기 제1 리소스와 연관된 제1 노드 및 상기 제2 리소스와 연관된 제2 노드는 장치관리 트리에 포함되는 것을 특징으로 한다.
또한 일 실시 예에 있어서, 상기 제1 리소스에 대한 제2 타입의 캐시 검증자가 존재하는지 판단하는 단계는, 현재 노드에서 상기 제1 리소스에 대한 제2 타입의 캐시 검증자를 검색하는 단계; 상기 현재 노드의 부모 노드를 상기 현재 노드로 설정하는 단계; 및 상기 제1 리소스에 대한 제2 타입의 캐시 검증자가 처음 발견될 때까지 상기 검색하는 단계 및 상기 설정하는 단계를 반복하는 단계를 포함하고, 상기 현재 노드는, 초기에 상기 제1 노드의 부모 노드로 설정되는 것을 특징으로 한다.
또한 일 실시 예에 있어서, 상기 제1 리소스에 대한 제2 타입의 캐시 검증자가 존재하는지 판단하는 단계는, 상기 제1 노드의 부모 노드부터 상기 장치관리 트리의 루트 노드까지 상기 제1 리소스에 대한 하나 이상의 제2 타입의 캐시 검증자를 검색하는 단계를 포함하는 것을 특징으로 한다.
또한 일 실시 예에 있어서, 상기 제1 리소스에 대한 제2 타입의 캐시 검증자가 존재하는지 판단하는 단계는, 상기 제1 리소스에 대한 하나 이상의 제2 타입의 캐시 검증자 중에서 상기 제1 리소스에 대한 제2 타입의 캐시 검증자를 선택하는 단계를 포함하는 것을 특징으로 한다.
또한 일 실시 예에 있어서, 상기 제1 리소스 및 제2 리소스는, 각각 대응하는 식별자에 의해 식별될 수 있는 네트워크 데이터 오브젝트 또는 서비스인 것을 특징으로 한다.
또한 일 실시 예에 있어서, 상기 장치관리 서버의 리소스 획득 방법은, 상기 제1 리소스에 대한 제1 타입의 캐시 검증자가 존재하는 경우에, 상기 제1 리소스에 대한 식별자 및 상기 제1 리소스에 대한 캐시 검증자를 이용하여 상기 장치관리 클라이언트에 상기 제1 리소스에 대한 요청을 송신하는 단계를 더 포함하는 것을 특징으로 한다.
또한 일 실시 예에 있어서, 상기 장치관리 서버의 리소스 획득 방법은, 상기 제1 리소스에 대한 제2 타입의 캐시 검증자가 존재하지 않는 경우에, 상기 제1 리소스에 대한 식별자를 이용하여 상기 장치관리 클라이언트에 상기 제1 리소스에 대한 요청을 송신하는 단계를 더 포함하는 것을 특징으로 한다.
한편, 본 명세서에 개시된 일 실시 예에 따른 장치관리 클라언트가 장치관리 서버에 리소스를 제공하는 방법은, 상기 장치관리 서버로부터 제1 리소스에 대한 요청을 수신하는 단계; 여기에서, 상기 요청은 상기 제1 리소스에 대한 제1 타입 또는 제2 타입의 캐시 검증자(cache validator)를 포함하고, 상기 제1 타입의 캐시 검증자는 상기 제1 리소스를 위해 직접적으로 사용되고, 상기 제2 타입의 캐시 검증자는 상기 제1 리소스를 포함하는 제2 리소스를 위해 사용되고, 상기 요청이 상기 제1 타입의 캐시 검증자를 포함하는 경우에, 상기 제1 타입의 캐시 검증자가 상기 제1 리소스에 대해 유효하면 상기 제1 리소스가 변경되지 않았음을 나타내는 메시지를 상기 장치관리 서버에 송신하는 단계; 및 상기 요청이 상기 제2 타입의 캐시 검증자를 포함하는 경우에, 상기 제2 타입의 캐시 검증자가 상기 제2 리소스에 대해 유효하면 상기 메시지를 상기 장치관리 서버에 송신하는 단계를 포함하는 것을 특징으로 한다.
일 실시 예에 있어서, 상기 제2 타입의 캐시 검증자가 상기 제2 리소스에 대해 유효하면 상기 메시지를 송신하는 단계는, 선택적으로, 상기 장치관리 클라이언트에 저장된 제1 리소스에 대한 제1 타입의 캐시 검증자가 존재하는 경우, 상기 제1 타입의 캐시 검증자를 이용하여 상기 메시지를 송신하는 단계인 것을 특징으로 한다.
또한 일 실시 예에 있어서, 상기 장치관리 클라이언트의 리소스 제공방법은, 상기 제1 타입의 캐시 검증자가 상기 제1 리소스에 대해 유효하지 않거나 상기 제2 타입의 캐시 검증자가 상기 제2 리소스에 대해 유효하지 않으면, 상기 제1 리소스를 상기 장치관리 서버에 송신하는 단계를 더 포함하는 것을 특징으로 한다.
또한 일 실시 예에 있어서, 상기 제1 리소스를 송신하는 단계는, 상기 장치관리 클라이언트에 저장된 제1 리소스에 대한 제1 타입의 캐시 검증자가 존재하는 경우, 상기 제1 타입의 캐시 검증자를 상기 제1 리소스와 함께 송신하는 단계인 것을 특징으로 한다.
또한 일 실시 예에 있어서, 상기 제1 리소스와 연관된 제1 노드 및 상기 제2 리소스와 연관된 제2 노드는 장치관리 트리에 포함된 것을 특징으로 한다.
또한 일 실시 예에 있어서, 상기 제1 리소스 및 제2 리소스는, 각각 대응하는 식별자에 의해 식별될 수 있는 네트워크 데이터 오브젝트 또는 서비스인 것을 특징으로 한다.
본 발명에 따르면, DM 서버가 캐시되지 않은 리소스를 요청할 때, 요청된 리소스를 포함하는 다른 리소스의 캐시 검증자를 이용함으로써, DM 리소스의 전송이 감소되어 네트워크 대역폭과 소비 전력이 절약될 수 있다.
또한, 본 발명은 특정 캐시 검증자, 예를 들어, ETag, Last-Modified 등 캐시 검증자에 상관없이 적용될 수 있고, 트랜스포트 바인딩 이하의 어떠한 것과도 결합될 수 있는 이점이 존재한다.
도 1은 RESTful DM에 대한 간략한 개념도이다.
도 2는 본 발명의 실시 예들에 따른 장치 관리 아키텍쳐를 나타내는 도면이다.
도 3은 본 발명의 일 실시 예에 따른 RESTful DM에서 리소스 요청을 할 때, 인클루시브 캐시 검증자를 이용하여 요청을 하는 과정을 나타낸 흐름도이다.
도 4는 본 발명의 일 실시 예에 따른 DM 클라이언트가 DM 리소스에 대한 요청을 받아 처리하는 과정을 나타내는 흐름도이다.
도 5의 (a) 및 (b)는 본 발명의 일 실시 예에 따른 DM 트리의 변경 내용을 보여주는 개념도이다.
도 6은 본 발명의 일 실시 예에 따라 리프 노드의 캐시 검증자를 업데이트하는 과정을 나타내는 흐름도이다.
도 7은 본 발명의 일 실시 예에 따라 내측 노드의 캐시 검증자를 업데이트하는 과정을 나타내는 흐름도이다.
도 8은 도 6 및 도 7에 도시된 캐시 검증자를 업데이트하는 과정을 나타내는 개념도이다.
도 9는 본 발명의 일 실시 예에 따른 DM 서버가 가벼운 리소스 캐싱에 따라 DM 클라이언트에 리소스를 요청하는 과정을 나타내는 흐름도이다.
도 10은 본 발명의 일 실시 예에 따른 DM 클라이언트가 가벼운 리소스 캐싱에 따라 DM 서버에 응답하는 과정을 나타내는 흐름도이다.
도 11은 본 발명의 일 실시 예에 따른 DM 클라이언트(110)가 PKG#1으로 응답을 보내는 과정을 나타내는 흐름도이다.
도 12는 본 발명의 일 실시 예에 따른 단말(200) 및 서버(300)의 블록도이다.
이하, 첨부된 도면을 참조하여 DM 서버와 DM 클라이언트가 서로 DM 리소스를 주고 받을 때 사용할 수 있는 캐시 방법에 대해 상세히 설명한다. 본 방법은 DM 리소스 간의 포함 관계를 고려한 효율적인 캐시 방법이다. 이를 위해 DM 리소스 캐싱에서 사용되는 개념인 인클루시브 캐시(Inclusive Cache), 인클루시브 캐시 검증자(Inclusive Cache Validator)에 대해 설명하고, 이를 바탕으로 DM 리소스 요청과 DM 리소스 응답에 대해 시퀀스를 기반으로 상세히 설명한다.
이하의 설명에서, “Hypertext Transfer Protocol -- HTTP/1.1”의 명칭을 갖는 RFC2616(http://www.w3c.org)의 [HTTP1.1], “OMA Device Management Protocol”의 명칭을 갖는 OMA-TS-DM_Protocol-V1_3(http://www.openmobilealliance.org)의 [DM1.3] 및 “Device Management HTTP Binding”의 명칭을 갖는 OMA-TS-DM_HTTPBinding-V1_3(http://www.openmobilealliance.org)의 [DM-HTTP-Binding]은 본 명세서에 참조로써 편입된다.
이하의 설명에서, 리소스(Resource)는 일반적으로 전자 문서, 이미지, 서버 및 다른 리소스들의 컬렉션(collection)이 될 수 있다. DM 리소스는 장치관리 동작을 위해 DM 서버와 DM 클라이언트 사이에 교환되는 일종의 리소스를 말한다. 다른 관점에서, DM 리소스는 각각 대응하는 식별자에 의해 식별될 수 있는 네트워크 데이터 오브젝트 또는 서비스를 말한다. DM 리소스의 전형적인 예가 DM 트리(또는 DM 트리의 일부)이다. DM 리소스는 URI에 의해 유일하게 식별되고, 이를 위해 절대 URI 주소 지정(addressing)이 사용될 수 있다.
캐싱(caching)은 서버들과 클라이언트들 사이의 리소스의 사본(copy)(예를 들어, 웹 캐시)을 저장하는 기술을 가리키는 일반적인 용어이다. 클라이언트는 서버로부터의 이전 응답을 저장하고, 동일한 리소스가 요청되면 그 사본을 재사용한다.
리소스를 교환할 때, 서버와 클라이언트는 각 리소스를 식별하는 URI를 사용한다. 서로 다른 URI들은 그 URI들에서 발견된 리소스들이 아무런 관계가 없음을 의미한다. 그러나, DM에서, 서로 다른 URI들의 DM 리소스들은 포함 관계에 있을 수 있다. URI1의 DM 리소스 R1은 다른 URI2의 DM 리소스 R2를 포함할 수 있다. 예를 들어, “./a/b?list=StructData”에 의해 식별되는 DM 트리 리소스는 “./a/b/c?list=StructData”에 의해 식별되는 다른 DM 트리 리소스를 포함할 수 있다.
캐시 검증자(Cache Validator)는 캐시 검증에 사용될 수 있는 컴포넌트이다. 캐시 검증은 요청자(requestor)에 캐시된 리소스가 최신인지(fresh) 아닌지를 판단하는 과정이다. ‘최신의(fresh)’라는 용어는 리소스가 요청자에 전송된 이후로 변경되지 않았음을 의미한다. 웹 캐시에서 사용되는 캐시 검증자의 전형적인 예는 Etag, 그리고 Last-Modified 필드이다.
캐시된 리소스가 요청될 리소스를 포함하면 그 캐시는 인클루시브 캐시(Inclusive Cache)이다. DM에서, 리소스들은 포함 관계에 있을 수 있고, 리소스 R1은 다른 리소스 R2를 포함할 수 있다. 요청자가 R2를 요청할 때, 요청자는 R2에 대한 다이렉트 캐시(Direct Cache)를 가지고 있지 않더라도 R1이 캐시되면 R1을 인클루시브 캐시로 사용할 수 있다.
캐시된 리소스가 직접적으로 요청된 리소스를 위한 것이면, 그 캐시는 다이렉트 캐시이다. 이 용어는 다이렉트 캐시를 인클루시브 캐시와 구별하기 위해 사용된다. 웹 캐시에서, 모든 캐시는 다이렉트 캐시이다.
인클루시브 캐시 검증자(Inclusive Cache Validator)는 인클루시브 캐시를 검증하는데 사용되는 캐시 검증자이다. Etag 및 Last-Modified 필드는 인클루시브 캐시 검증자가 될 수 있다.
다이렉트 캐시 검증자(Direct Cache Validator)는 다이렉트 캐시를 검증하는데 사용되는 캐시 검증자이다. Etag 및 Last-Modified 필드는 다이렉트 캐시 검증자가 될 수 있다.
도 2는 본 명세서에 개시된 실시 예들에 따른 장치 관리 아키텍쳐를 나타내는 도면이다.
장치관리(DM)는 DM 클라이언트(110) 및 DM 서버(120)를 포함하는 DM 인에이블러(100)에 의해 수행된다.
DM 클라이언트(110)는 OMA(Open Mobile Alliance) 장치 관리 인에이블러에 명시된 DM 클라이언트의 요구사항을 따르는 추상적인 소프트웨어 컴포넌트이다.
DM 서버(120)는 OMA 장치 관리 인에이블러에 명시된 DM 서버의 요구사항을 따르는 추상적인 소프트웨어 컴포넌트이다.
클라이언트-서버 알림(DM-1)은 서버(120)들이 클라이언트(110)들에 장치 관리 알림을 보낼 수 있는 인터페이스를 제공한다. 클라이언트-서버 알림(DM-1)은 중간 운반자이고, WAP 푸쉬 및 SIP 푸쉬와 같은 많은 프로토콜을 통해 동작할 수 있는 인터페이스이다.
장치 관리 클라이언트-서버 프로토콜(DM-2)은 서버(120)들이 클라이언트(110)들에 장치 관리 명령들을 송신하고, 클라이언트(110)들이 서버(120)들에 상태 및 알람을 송신할 수 있는 인터페이스를 제공한다. 장치 관리 클라이언트-서버 프로토콜(DM-2)은 중간 운반자이고, HTTP 및 HTTPS를 포함하는 많은 표준화된 바인딩을 제공하는 인터페이스이다. 이 인터페이스는 무선통신(over-the-air) 장치 관리 성능을 제공하기 위해 무선연결-기반 데이터 전달 프로토콜(예를 들어, GPRS)을 통해 노출된다.
DM 클라이언트(110)는 초기에 스마트 카드(210) 상의 파일을 통해 공급될 수 있다. 이 파일은 DM 클라이언트(110)에서 설정을 셋팅하거나 변경하기 위한 일련의 DM 명령들을 포함한다. 스마트 카드(210)를 통한 DM 부트스트랩 프로파일(DM-3)은 DM 클라이언트(110)로부터의 피드백이 제공되지 않는 단방향의 인터페이스이다. 다음의 실질적인 기회에서 DM 서버(120)에 연결되는 DM 클라이언트(110)가 유일한 기대 결과이다.
DM 클라이언트(110)는 초기에 몇몇 푸쉬 프로토콜에 의해 전송된 파일을 통해 공급될 수 있다. 이 파일은 DM 클라이언트에서 설정을 셋팅하거나 변경하기 위한 DM 명령들을 포함한다. 부트스트랩 프로파일 OTA(DM-4)는 DM 클라이언트(110)로부터의 피드백이 제공되지 않는, OTA 서버(220)에서 DM 클라이언트(110)로의 단방향의 인터페이스이다. 다음의 실질적인 기회에서 DM 서버(120)에 연결되는 DM 클라이언트(110)가 유일한 기대 결과이다.
DM 클라이언트(110)는 초기에 CP 인에이블러(230)를 통해 공급될 수 있다. CP 부트스트랩 프로파일(CP-1)은 DM 클라이언트(110)로부터의 피드백이 제공되지 않는, CP 인에이블러(230)에서 DM 클라이언트(110)로의 단방향의 인터페이스이다. 다음의 실질적인 기회에서 DM 서버(120)에 연결되는 DM 클라이언트(110)가 유일한 기대 결과이다.
인클루시브 캐시 및 인클루시브 캐시 검증자
RESTful DM은 DM 서버(120)와 DM 클라이언트(110)사이에 DM 메시지를 전송하기 위해 HTTP 프로토콜을 이용한다. HTTP를 이용한 기존의 DM 트랜스포트 바인딩으로 DM HTTP 바인딩[DM-HTTP-Binding]을 들 수 있지만, RESTful DM과 DM HTTP 바인딩은 차이가 크다. 개념적으로 RESTful DM이 REST 아키텍처를 따른다고 볼 수도 있지만, 외형적인 가장 큰 차이는 RESTful DM은 DM 명령을 HTTP 메소드(method)로 대체하여 HTTP 헤더에 표현한다는 점이다. 즉 DM HTTP 바인딩에서는 실제 DM 명령과 무관하게 POST 메소드를 HTTP 헤더에 넣고, DM 명령은 HTTP 바디에 들어간다. 하지만 RESTful DM에서는 하나의 예로, DM Get 명령을 HTTP GET 메소드로 바꾸어, HTTP 헤더에 넣게 된다. RESTful DM은 이렇게 관련 HTTP 헤더를 폭넓게 이용하기 때문에, HTTP 프로토콜과 더 강하게 결합되고, HTTP 프로토콜의 장점을 그대로 이용할 수 있게 된다. 예로, RESTful DM에서 HTTP 캐싱 이용이 가능하다.
RESTful DM은 DM 명령을 HTTP 메소드로 대체한다. HTTP 프로토콜은 URI로 구분되는 리소스에 대해 특정 메소드를 전달하는데, 가장 간단한 예로 ‘GET http://www.server.com/img.jpg’를 생각할 수 있다. 이는 URI ‘http://www.server.com/img.jpg’로 지정한 리소스를 얻어오는 것이다. RESTful DM도 이와 마찬가지로 URI와 그 URI에 대한 메소드를 보내 DM 메시지를 전달하는데, 여기서 DM 리소스를 URI로 일관되게 나타낼 수 있어야 한다. 이 방법은 아직 OMA DM WG에서 정의하지 않았지만, 본 발명에서는 일반적으로 생각할 수 있는 다음의 표 5의 방법을 사용한다. 이 방법으로, DM의 절대 URI 주소 지정(Absolute URI Addressing)에서 “./SCOMO/Download”라고 표현되는 노드에 대한 StructData 속성(attribute)은 “http://dev_addr:dm_port/SCOMO/Download?list=StructData”라고 표현된다.
표 5
http://dev_addr:dm_port/absolute_path_from_root?property_or_atrribute
DM의 리소스에 HTTP 캐싱을 사용할 수 있다는 점은 RESTful DM의 한 장점이지만, HTTP 캐싱을 DM에 그대로 적용하면 하는 것은 비효율적이다. 이는 HTTP에서 URI로 지정되는 리소스 간에 상관 관계가 없지만, DM 리소스 간에는 포함 관계(inclusive relationship) 가 있기 때문이다. 즉 URI1으로 지정되는 R1이라는 리소스가 URI2로 지정되는 R2 리소스를 포함하는 관계가 DM 프로토콜에서는 성립한다.
다음의 표 6은 이러한 DM 리소스 간의 포함 관계를 나타낸다. 표 6을 참조하면, “./a/b?list=Struct”이 나타내는 리소스는 “./a/b/c?list=Struct” 리소스를 포함하고 있다. 이 표는 DM 리소스의 모든 포함 관계를 나타낸 것은 아니며, 몇 가지 포함 관계에 대한 예를 보여주고 있다.
표 6
A B A가 B를 포함하는지 여부
./a/b ./a/b/c 미포함
./a/b?list=Struct ./a/b/c?list=Struct 포함
./a/b?list=StructData ./a/b/c?list=StructData 포함
./a/b?list=StructData ./a/b/c?list=Struct 포함
./a/b?list=Struct ./a/b/c?list=StructData 미포함
./a/b?list=MORoot ./a/b/c?list=MORoot MO 식별자가 동일한 경우에만 포함
./a/b?list=MORootData ./a/b/c?list=MORootData MO 식별자와 요청된 리프 노드가 동일한 경우에만 포함
./a/b?list=TNDS ./a/b/c?list=TNDS 포함
따라서 DM 리소스를 DM 서버와 DM 클라이언트 사이에서 주고 받을 때, 이러한 DM 리소스 간의 포함 관계를 고려하면, 더 효율적인 캐싱 메커니즘을 만들 수가 있다. HTTP에서는 서로 다른 URI를 갖는 리소스는 별도로 보며, 이들 간의 캐시 검증자를 비교하는 것은 무의미한 것으로 본다. 하지만 DM에서는 서로 다른 URI를 갖는 리소스에 대한 캐시 검증자를 포함 관계를 고려하여 비교하면 캐시 메커니즘의 효율성을 향상시킬 수 있다. 이를 위해, 다이렉트 캐시와 인클루시브 캐시라는 개념을 본 발명에 도입하였다. 다이렉트 캐시는 기존의 HTTP 프로토콜에서 허용하는 캐시 개념으로, URI1의 리소스를 요청할 때, URI1에 대한 직접적인 캐시를 가지고 있는 경우이다. 반면, 인클루시브 캐시는 URI1으로 지정되는 리소스를 요청할 때, URI1에 대한 다이렉트 캐시를 가지고 있지 않더라도, 요청하는 리소스를 포함하는 다른 리소스를 가지고 있는 경우이다. 즉 “./a/b/c?list=Struct”라는 URI를 통해 DM 리소스를 요청할 때, “./a/b/c?list=Struct”에 대한 캐시된 리소스 버전이 있다면, 이는 다이렉트 캐시이다. 하지만 이런 다이렉트 캐시는 없지만, “./a/b?list=Struct”에 대한 캐시된 리소스 버전이 있다면, 이를 인클루시브 캐시라고 한다.
캐시 검증자란 로컬에 캐시하고 있는 리소스 버전이 최신 버전인지 아닌지에 관한 정보를 제공해 주는 일종의 지시자이다. HTTP 캐싱에서는 캐시 검증자로써 ETag와 Last-Modified가 많이 사용되며, 다이렉트 캐시인지 인클루시브 캐시인지 상관없이 동일한 방식의 캐시 검증자가 적용될 수 있다. 즉 ETag와 Last-Modified 모두 다이렉트 캐시, 인클루시브 캐시에 모두 적용가능하며 동작 방식 역시 동일하다.
본 발명에서는 DM 리소스를 DM 서버와 DM 클라이언트 사이에서 주고 받을 때, 기존의 다이렉트 캐시에 추가로 인클루시브 캐시를 활용하는 방법을 제안하는 것이다. 이를 위해서는 DM 리소스를 요청하는 엔티티 (일반적으로 DM 서버)와, 요청에 대해 응답하는 엔티티(일반적으로 DM 클라이언트)가 모두 바뀌어야 한다.
DM 리소스 캐싱을 위한 요청 과정
도 3은 본 발명의 일 실시 예에 따른 RESTful DM에서 리소스 요청을 할 때, 인클루시브 캐시 검증자를 이용하여 요청을 하는 과정을 나타낸 흐름도이다. DM 리소스를 요청하는 엔티티가 반드시 DM 서버가 아니어도 상관없지만, 여기서는 DM 서버라고 가정하고 설명한다.
DM 서버(120, DMS) 는 URI1으로 지정되는 리소스를 DM 클라이언트(110, DMC)에게 요청할 것을 결정한다(S110).
DM 서버(120)는 URI1에 대한 요청을 보내기 전에, DM 서버(120)가 캐시된 리소스를 가지고 있는지 확인한다(S120). 캐시는 다이렉트 캐시가 될 수도 있고, 인클루시브 캐시가 될 수도 있다. 따라서 본 단계에서 검색된 캐시는 다수가 될 수 있다.
DM 서버(120)는 다양한 방식으로 인클루시브 캐시를 검색할 수 있다. 예를 들어, 초기에 DM 서버(120)는 요청할 리소스에 대응하는 노드의 부모 노드를 현재 노드로 설정한다. 그리고, DM 서버(120)는 현재 노드에서 요청할 리소스에 대한 인클루시브 캐시 검증자를 검색한다. 그리고, DM 서버(120)는 현재 노드의 부모 노드를 새로운 현재 노드로 설정한다. DM 서버(120)는 요청할 리소스에 대한 인클루시브 캐시 검증자가 처음으로 발견될 때까지 인클루시브 캐시 검증자의 검색과 새로운 현재 노드 설정 과정을 반복하여 수행한다.
또한, 예를 들어, DM 서버(120)는 요청할 리소스에 대응하는 노드의 부모 노드부터 DM 트리의 루트 노드까지 요청할 리소스에 대한 인클루시브 캐시 검증자를 검색한다.
DM 서버(120)가 어떤 캐시도 가지고 있지 않다면, DM 서버(120)는 DM 클라이언트(110)에 캐시없이 요청을 보낸다(S130). 요청은 URI1을 포함하며, 구체적인 내용은 요청 내용에 따라 다르다. 다만 캐시가 없기 때문에, 요청에 캐시 관련 정보는 포함되지 않는다.
DM 서버(120)는 제120 단계에서 발견된 캐시가 다수인지 확인한다(S140).
만약 제120 단계에서 발견된 캐시가 다수라면, 그 중에서 하나를 선택한다(S150). 캐시를 선택하기 위해 고려할 수 있는 요소는 캐시 타입(Cache type), 캐시 생성 시간(Cache generation time) 및 캐시 범위(Cache range) 등을 포함한다.
캐시 타입은 캐시가 다이렉트 캐시인지 또는 인클루시브 캐시인지를 나타내며, 다이렉트 캐시의 경우 인클루시브 캐시의 경우보다 캐시 유효성 판단이 간단하여 효율적이다.
캐시 생성 시간은 시간상으로 나중에 생성된 캐시가 캐시 히트(cache hit)의 확률이 높다. 일반적으로 캐시 히트는 캐시 클라이언트(CPU, 웹 브라우저, 운영체계)가 보조 기억 장치에 존재하는 것으로 추정되는 데이터에 접근할 때, 캐시를 검사하여 원하는 데이터의 엔트리에 매칭되는 태그가 엔트리로 발견되면 그 엔트리를 데이터 대신에 사용하는 상황을 의미한다. 이하의 설명에서, 캐시 히트는 DM 클라이언트(110)에서 DM 서버(120)로부터 수신한 캐시 검증자가 유효한 상황을 의미한다.
캐시 생성 시간은 시간상으로 나중에 생성된 캐시가 캐시 히트의 확률이 높다.
캐시 범위는 캐시 범위가 좁은 캐시일수록 캐시 히트의 확률이 높고, 유효성 판단이 더 간단하다. 즉 넓은 범위를 포함하는 캐시의 경우, 해당 리소스가 업데이트될 확률이 커서, 캐시 미스(cache miss)의 확률이 높아진다. 이하의 설명에서, 캐시 미스는 DM 클라이언트(110)에서 DM 서버(120)로부터 수신한 캐시 검증자가 유효하지 않은 상황을 의미한다.
또한 캐시 히트의 가능성을 높이기 위해, 리소스 변경을 추적할 경우, 캐시의 범위가 넓을수록 더 많은 리소스를 추적해야 하므로, 부하가 커진다.
제140 단계 및 제150 단계를 통해 하나의 캐시가 선정된 상태에서, DM 서버(120)는 선정된 하나의 캐시가 다이렉트 캐시인지 인클루시브 캐시인지 확인한다(S160).
선택된 캐시가 다이렉트 캐시인 경우, DM 리소스에 대한 요청은 HTTP 캐싱의 방법을 따른다. 즉, DM 리소스에 대한 요청은 요청하는 리소스에 대한 URI1, 그리고 캐시 검증자를 포함한다(S170). 여기서 캐시 검증자는 다이렉트 캐시 검증자이기 때문에 URI1에 대한 캐시된 리소스를 위해 직접적으로 사용되는 캐시 검증자이다.
본 단계는 인클루시브 캐시 검증자를 사용하여 DM 리소스를 요청하는 경우이다. DM 리소스 요청을 위해 URI1(요청하는 리소스의 URI) 과 선택된 캐시에 대한 인클루시브 캐시 검증자, 그리고 선택된 캐시에 대한 URI를 포함한 요청을 DM 클라이언트에게 보내게 된다(S180).
DM 리소스 캐싱을 위한 응답 과정
도 4는 본 발명의 일 실시 예에 따른 DM 클라이언트가 DM 리소스에 대한 요청을 받아 처리하는 과정을 나타내는 흐름도이다. 응답 과정이라고 볼 수 있는 이 과정에서, 응답을 처리하는 부분이 반드시 DM 클라이언트가 될 필요는 없지만, 여기서는 DM 클라이언트라고 가정하고 설명한다.
DM 클라이언트(110)는 DM 서버(120)로부터 URI1에 대한 DM 리소스를 요청 받는다(S210).
DM 클라이언트(110)는 요청 메시지에 다이렉트 캐시 검증자(ETag나 Last-Modified)가 포함되어 있는지 확인한다(S220). HTTP 헤더에 If-None-Match 필드가 포함되어 있다면, 캐시 검증자인 ETag를 포함하고 있다는 뜻이며, If-Modified-Since 필드를 포함하고 있다면, 캐시 검증자인 Last-Modified가 포함되어 있다고 판단할 수 있다.
다이렉트 캐시 검증자는 HTTP 캐시의 기본 동작이기 때문에 본 스텝은 HTTP의 기본 동작과 일치한다. DM 클라이언트(110)는 캐시 검증자를 통해 DM 서버(120)가 캐시하고 있는 리소스 버전이 최신 버전인지 확인할 수가 있다(S230). 캐시 검증자가 Etag인 경우, 요청 메시지에 포함되어 있는 ETag의 값과 DM 클라이언트(110)가 가지고 있는 Etag 값이 일치하면 DM 클라이언트(110)는 캐시가 유효한 것으로 판단한다. Last-Modified는 마지막 수정 시간을 나타내므로, 요청에 포함되어 있는 마지막 수정 시간 이후에, 해당 리소스가 수정되었는지 확인해서 유효성을 판단할 수 있다.
캐시가 유효하여 캐시 히트가 발생하면, DM 서버(120)가 캐시하고 있는 버전이 최신 버전이기 때문에, 리소스를 다시 전송하지 않는다(S240). HTTP에서는 ‘304 Not Modified’ 상태 코드를 전송하여 이러한 캐시 히트를 알려준다.
다이렉트 캐시 검증자가 없는 경우, DM 클라이언트(110)는 인클루시브 캐시 검증자가 있는지 확인한다(S250). RESTful DM의 경우, 인클루시브 캐시 검증자 역시 HTTP 헤더를 통해 전달될 수 있다. 하지만 어떤 종류의 캐시 검증자인지 헤더 이름을 통해 구분하므로, 사용되는 필드의 이름은 서로 달라야 한다. 예로 ETag의 경우, Inclusive-If-None-Match 라는 헤더 필드를 사용할 수 있고, Last-Modified의 경우 Inclusive-If-Modified-Since 라는 헤더 필드를 사용할 수 있다. 인클루시브 캐시 검증자의 경우, 다이렉트 캐시 검증자와 다르게 추가로 하나의 URI를 더 HTTP 헤더에 포함해야 한다. 이 URI는 도 3의 제180 단계에서 설명한 캐시를 위한 URI라는 항목으로, DM 서버(120)의 로컬에 있는 캐시된 리소스가 어떤 URI에 대한 캐시인지를 나타낸다. 이 URI가 요청 메시지에 포함되어 있지 않다면, 캐시의 유효성 여부를 확인할 수가 없게 된다. 이는 캐시 검증자 만으로는 해당 캐시가 어떤 리소스에 대한 캐시인지 알 수 없기 때문이다. 이 URI를 표시하기 위해 HTTP 헤더에 Inclusive-Cache-URI라는 헤더를 포함할 수 있다.
DM 클라이언트(110)는 수신한 인클루시브 캐시 검증자를 이용해 DM 서버(120)가 로컬에 가지고 있는 URI1에 대한 캐시가 유효한지 확인한다(S260). 인클루시브 캐시 검증자의 경우 제250 단계에서 설명한 것과 같이, 추가로 하나의 URI를 더 포함하고 있다. 이 URI는 인클루시브 캐시가 실제 어떤 리소스에 대한 캐시인지를 나타내며, 이 URI를 여기서는 IC_URI 라고 가정한다. IC_URI가 나타내는 리소스는 URI1이 나타내는 리소스를 포함한다 (포함 관계). DM 클라이언트(110)는 IC_URI의 인클루시브 캐시 검증자를 통해 IC_URI에 대한 리소스가 변경되었는지 확인할 수 있다. IC_URI 리소스가 변경되지 않았다면, URI1에 대한 리소스도 변경되지 않았다는 뜻이다. 또한 IC_URI가 나타내는 리소스는 변경되었더라도, URI1이 나타내는 리소스가 변경되지 않았다면, DM 서버(120)의 URI1에 대한 캐시가 유효하다고 판단할 수 있다. 하지만 이를 위해서, DM 클라이언트(110)는 변경된 DM 리소스에 대한 추적 정보를 저장하고 있다가, 각각의 변경이 IC_URI의 리소스에 대한 변경인지, URI1의 리소스에 대한 변경인지 확인하여야 한다.
캐시가 유효하지 않아 캐시 미스가 발생한 경우, DM 클라이언트(110)는 DM 서버(120)에게 전체 리소스(리소스에 대한 전체 버전)를 보내게 된다(S270). 또 전송하는 리소스인 URI1에 대한 캐시 검증자를 전송하게 된다. 전송된 캐시 검증자는 나중에 동일 리소스를 요청할 때, DM 서버(120)가 사용할 수 있다.
캐시가 유효하여 캐시 히트가 발생한 경우, DM 클라이언트(110)는 DM 서버(120)에게 리소스를 다시 전송할 필요가 없다. 하지만 DM 서버(120)는 URI1에 대한 다이렉트 캐시 검증자를 가지고 있지 않기 때문에, URI1에 대한 캐시 검증자를 전송해 준다(S280). 이 다이렉트 캐시 검증자는 DM 서버(120)가 추후에 동일 리소스를 요청할 경우 이용할 수 있다. 이는 다이렉트 캐시가 인클루시브 캐시에 비해 처리 과정이 간단하기 때문이다. HTTP에서는 캐시 히트를 알려주기 위해 ‘304 Not Modified’ 상태 코드를 사용하고 있으며, 같은 방법을 RESTful DM에 적용해 DM 클라이언트(110)는 DM 서버(120)에게 캐시 히트를 알려줄 수 있다.
캐시 미스를 위한 델타(Delta) 응답
도 4의 제270 단계를 참조하여 설명한 바와 같이, 캐시 미스가 발생한 경우, DM 클라이언트(110)는 요청한 리소스에 대한 전체 리소스를 DM 서버(120)에 송신한다. 하지만, 전체 요청한 리소스의 일부만이 변경된 경우, 전체 리소스(full 버전)를 보내는 것은 비효율적이다. 이때, 전체 리소스가 아닌 변경된 부분만을 보낼 수가 있으며, 이를 델타 응답이라고 한다.
도 5의 (a) 및 (b)는 본 발명의 일 실시 예에 따른 DM 트리의 변경 내용을 보여주는 개념도이다.
도 5의 (a)에 도시된 DM 트리에 대해 DM 서버(120)는 루트에 대한 Get을 수행하여, 전체 DM 트리 및 루트(/)에 대한 캐시 검증자(CV1)를 로컬에 저장하고 있다. 이때 DM 트리가 도 5의 (b)와 같이 업데이트 되었다고 가정한다. 업데이트 될 시, 루트에 대한 캐시 검증자 역시 업데이트가 된다. 루트에 대한 새로운 캐시 검증자를 CV2라고 가정한다. 이제, DM 서버(120)가 CV1을 가지고 root (/)에 대해 Get을 수행하면, DM 클라이언트(110)는 CV1이 자신이 저장하고 있는 루트에 대한 캐시 검증자인 CV2와 다르기 때문에, 전체 리소스를 보내게 된다. 여기까지가 도 4를 참조하여 설명한 부분이다.
하지만, 전체 리소스를 보내는 대신, 변경된 부분만 보내게 되면, 더 효율적이며, 이렇게 변경된 부분만 보내는 것을 델타 응답이라고 한다. 델타 응답은 기존 노드의 업데이트, 새로운 노드의 추가, 기존 노드의 삭제 등을 포함할 수 있다.
본 발명의 일 실시 예에 대한 설명
다음의 표 7은 RESTful DM에서 인클루시브 캐시를 이용한 DM 리소스 캐싱 방법을 보여주는 예이다.
표 7
Request 1
Get http://dev_ip:dm_port/SCOMO/Download?list=StructData HTTP/1.1
Response
HTTP/1.1 200 OKETag: “686897696a7c876b7e”// the resource is here in the HTTP body
Request 2
GET http://dev_ip:dm_port/SCOMO/Download/game1?list=StructData HTTP/1.1Inclusive-If-None-Match: “686897696a7c876b7e”Inclusive-Cache-URI: http://dev_ip:dm_port/SCOMO/Download?list=StructData
Response 2
HTTP/1.1 304 Not ModifiedETag: “1234dfef31221233ffe3” // the ETag for the URI requested// resource is not transferred
각각에 대해 상세히 설명하면 다음과 같다. DM 서버(120)는 DM 클라이언트(110)에 “http://dev_id:dm_port/SCOMO/Download?list=StructData” URI에 대한 리소스를 요청한다(Request1).
DM 클라이언트(110)는 요청을 받고, DM 서버(120)에게 해당 리소스를 전송한다(Response 1). 리소스는 HTTP 바디(body)를 통해 전송되며, DM 클라이언트(110)는 추가로 캐시 검증자를 전송한다. 표 7에서는 ETag가 캐시 검증자로 사용되었다.
DM 서버(120)는 DM 클라이언트(110)에게 “http://dev_ip:dm_port/SCOMO/Download/game1?list=StructData”를 요청한다(Request 2). 이 리소스에 대한 요청이 처음이기 때문에, 다이렉트 캐시 검증자가 로컬에 없다. 하지만 이전에 “http://dev_id:dm_port/SCOMO/Download?list=StructData”에 대한 요청을 했기 때문에, DM 서버(120)가 인클루시브 캐시를 가지고 있는 경우이다. 이 인클루시브 캐시를 요청 메시지에 포함시키기 위해서 Inclusive-If-None-Match 필드와 Inclusive-Cache-URI 필드를 이용한다. Inclusive-If-None-Match 필드는 인클루시브 캐시 검증자를 전달하는데 사용되고, Inclusive-Cache-URI는 인클루시브 캐시가 실제 어떤 리소스에 대한 캐시인지를 나타낸다.
DM 클라이언트(110)는 인클루시브 캐시 검증자를 이용해 실제 DM 서버(120)가 요청한 “http://dev_ip:dm_port/SCOMO/Download/game1?list=StructData” 에 대한 DM 서버(120)의 캐시가 유효한지 검사한다(Response 2). DM 클라이언트(110)는 Inclusive-If-None-Match를 통해 전달받은 인클루시브 캐시 검증자를 통해 “http://dev_id:dm_port/SCOMO/Download?list=StructData” 리소스가 변경되었는지를 검사한다. “http://dev_id:dm_port/SCOMO/Download?list=StructData” 리소스가 변경되지 않았다면, 하위 리소스인 “http://dev_ip:dm_port/SCOMO/Download/game1?list=StructData” 역시 변경되지 않았다는 뜻이므로, 캐시가 유효하다고 판단할 수 있다. 또한 “http://dev_id:dm_port/SCOMO/Download?list=StructData” 리소스가 변경되었더라도 변경내용을 추적해, “http://dev_ip:dm_port/SCOMO/Download/game1?list=StructData” 리소스가 변경되지 않았다면, 캐시가 유효하다고 판단할 수 있다.
DM을 위한 가벼운 리소스 캐싱
지금까지 인클루시브 캐시를 활용한 DM 리소스 캐싱 방법을 설명하였다. 이 방법은 DM 리소스 간의 포함 관계를 고려하여 효율적이기는 하지만, 단말에 부하가 큰 단점이 있다. 이러한 부하는 주로 캐싱을 위해 사용되는 캐시 검증자를 관리하는 데서 발생하는데, DM 서버(120)가 요청하는 개개의 URI 마다 모두 캐시 검증자를 두어야 하며, 해당 리소스가 업데이트될 때마다 관련된 캐시 검증자를 업데이트해야만 한다. 즉 DM 클라이언트(110)는 내측 노드(interior node)“/a/b”에 대해서 “/a/b”, “./a/b?list=Struct”, “./a/b?list=StructData”, “./a/b?list=MORoot”, “./a/b?list=MORootData”, “./a/b?list=TNDS”와 같은 각각의 속성에 대해서도 모두 별도의 리소스로 보고 캐시 검증자를 관리해야 한다. 이러한 오버헤드(overhead)는 단말의 성능 저하 원인이 될 수 있기 때문에, 효율적이면서도, 가벼운(lightweight) DM 리소스 캐싱 방법이 필요하다. 이하에서는 가벼운(lightweight) DM 리소스 캐싱 방법을 제안한다.
DM 트리는 리프 노드에 노드 값을 저장하며, 또한 접근 제어 목록(ACL; Access Control List), 형식(Format), 이름(Name), 크기(Size), 명칭(Title), TStamp, 타입(Type), VerNo의 노드 속성(property)을 통해 노드와 관련 있는 데이터를 저장한다. 이들 데이터 모두가 캐시 가능한 리소스이지만, 이들 중에서 노드 이름, 노드 값은 특히 중요한 리소스이다. 따라서, 가벼운 DM 리소스 캐싱을 위해 노드 URI(노드 이름의 시퀀스), 노드 값을 캐싱한다. 또한, 캐시 검증자를 노드 당 하나만을 할당하여 관리한다. 즉, 내측 노드 “./a/b”에 대해서, “./a/b”, “./a/b?list=Struct”, “./a/b?list=StructData”, “./a/b?list=MORoot”, “./a/b?list=MORootData”, “./a/b?list=TNDS”와 같이 각각의 URI에 별도의 캐시 검증자를 두지 않고, “./a/b” 노드에 하나의 캐시 검증자를 둔다. 이 내용을 다시 정리하면 다음과 같다.
캐시 검증자는 노드에 하나씩만 할당되고, 하나의 노드는 오직 하나의 캐시 검증자만을 갖는다.
리프 노드에 할당된 캐시 검증자는 리프 노드의 노드 URI와 노드 값을 커버한다. 다시 말해, 리프 노드의 노드 URI와 노드 값이 업데이트되면, 리프 노드의 캐시 검증자가 업데이트된다.
내측 노드에 할당된 캐시 검증자는 내측 노드의 노드 URI와 모든 자손 노드(내측 노드를 루트로 하는 서브-트리에서 내측 노드를 제외한 모드 노드)의 노드 URI 및 모든 자손 리프 노드의 노드 값을 커버한다. 내측 노드의 노드 URI와 모든 자손 노드의 노드 URI 및 모든 자손 리프 노드의 노드 값이 업데이트 되면, 내측 노드를 위한 캐시 검증자가 업데이트되어야 한다.
일반적으로 노드 URI는 루트 노드에서 그 노드에 이르는 모든 노드의 노드 이름과 구분 문자(delimiter)를 연결하여 구성이 되기 때문에, 노드 이름의 변경은 그 노드와 그 노드의 자손 노드의 노드 URI에 변경을 가져온다. DM에서는 노드 URI를 직접 변경할 수 있는 명령은 없고, 노드의 이름을 변경함으로써, 노드 URI를 변경할 수 있기 때문에, 도 6에서는 노드 이름 변경을 가지고 노드 URI 변경을 확인한다.
도 6은 본 발명의 일 실시 예에 따라 리프 노드의 캐시 검증자를 업데이트하는 과정을 나타내는 흐름도이다.
DM 클라이언트(110)는 리프 노드 A를 대상으로 하는 DM 명령을 DM 서버(120)로부터 받는다(S310).
DM 클라이언트(110)는 DM 명령이 기존의 노드를 변경하는 명령으로 리프 노드의 이름이나 값을 변경하는 명령인지 확인한다(S320).
DM 클라이언트(110)는 DM 명령이 노드 A를 새로 추가하는 명령인지 확인한다(S330).
DM 클라이언트(110)는 DM 명령이 기존의 노드 A를 삭제하는 명령인지 확인한다(S340).
DM 명령이 노드 이름이나 노드 값을 변경/추가/삭제하지 않는 경우에, DM 클라이언트(110)는 캐시 검증자를 업데이트 하지 않는다(S350).
노드 이름이나 노드 값이 변경된 경우 혹은 노드가 새롭게 추가된 경우, DM 클라이언트(110)는 노드 A로부터 루트 노드까지의 모든 노드(A 노드에서 root 노드까지의 최단 경로(shortest path) 위에 있는 모든 노드)의 캐시 검증자를 업데이트 한다(S360).
노드 이름이나 노드 값이 삭제된 경우, DM 클라이언트(110)는 A의 부모 노드로부터 시작하여, 루트 노드까지의 모든 노드(A의 부모 노드에서 루트 노드까지의 최단 경로 위에 있는 모든 노드)의 캐시 검증자를 업데이트 한다(S270).
도 7은 본 발명의 일 실시 예에 따라 내측 노드의 캐시 검증자를 업데이트하는 과정을 나타내는 흐름도이다.
DM 클라이언트(110)는 내측 노드 A를 대상으로 하는 DM 명령을 DM 서버(120)로부터 받는다(S410).
DM 클라이언트(110)는 DM 명령이 A의 노드 이름을 변경하는 명령인지 확인한다(S420).
DM 클라이언트(110)는 DM 명령이 노드 A를 새롭게 추가하는 명령인지 확인한다(S430).
DM 클라이언트(110)는 DM 명령이 노드 A를 삭제하는 명령인지 확인한다(S440).
DM 명령이 노드 이름을 변경하거나 노드를 추가/삭제하지 않은 경우, DM 클라이언트(110)는 캐시 검증자를 업데이트 하지 않는다(S450).
DM 명령이 노드 이름을 변경한 경우 또는 노드를 추가하는 경우, DM 클라이언트(110)는 노드 A로부터 루트 노드까지의 모든 노드(A에서 루트 노드까지의 최단 경로 위에 있는 모든 노드)의 캐시 검증자를 업데이트 한다. 또한 A를 루트 노드로 갖는 서브-트리 안의 모든 노드의 캐시 검증자를 업데이트 한다(S460). 이때 노드 A의 캐시 검증자는 이미 업데이트 되었기 때문에, 중복 수행하지 않는다.
DM 명령이 노드 A를 삭제하는 경우, DM 클라이언트(110)는 A의 부모 노드로부터 시작하여, 루트 노드까지의 모든 노드(A의 부모 노드에서 루트 노드까지의 최단 경로 위에 있는 모든 노드)의 캐시 검증자를 업데이트 한다(S470).
도 8은 도 6 및 도 7에 도시된 캐시 검증자를 업데이트하는 과정을 나타내는 개념도이다.
도 8에 도시된 DM 트리에는 루트 노드를 포함하여 총 7개의 노드가 있기 때문에, 단말은 각각의 노드마다 하나씩, 총 7개의 캐시 검증자를 관리한다. 이에 따라 URI마다 하나의 캐시 검증자를 두는 것보다 캐시 검증자의 개수를 훨씬 줄일 수가 있다. 만약, node1-1의 node value가 “사과”로 변경되었다면, DM 클라이언트(110)는 node1-1, node1, root 노드의 캐시 검증자를 업데이트한다. 그리고, node2-1-1 노드가 삭제되었다면, DM 클라이언트(110)는 node2-1, node2, root 노드의 캐시 검증자를 업데이트한다. 만약 node2-2 노드가 새롭게 추가된 경우라면, DM 클라이언트(110)는 node2-2, node2, root 노드의 캐시 검증자를 업데이트한다. 만약, node2 노드의 이름이 변경된 경우라면, DM 클라이언트(110)는 node2, root, node2-1, node2-2, node2-1-1의 캐시 검증자를 업데이트 한다.
DM 서버로부터의 리소스 요청
가벼운 리소스 캐싱을 이용한 리소스 요청도 도 3을 참조하여 설명한 리소스 요청 방식과 유사하다. 그러나, 도 3의 리소스 요청 방식은 URI 기반의 캐시 검증자를 사용하는 반면, 가벼운 리소스 캐싱은 노드 기반의 캐시 검증자를 두고, 또 노드 URI와 노드 값 만을 캐시 검증자가 커버하기 때문에 차이가 있다.
도 9는 본 발명의 일 실시 예에 따른 DM 서버가 가벼운 리소스 캐싱에 따라 DM 클라이언트에 리소스를 요청하는 과정을 나타내는 흐름도이다.
DM 서버(120)는 URI1으로 지정되는 리소스를 DM 클라이언트(110)에게 요청할 것을 결정한다(S510). URI1은 특정 노드 A를 지칭한다. 예로, “./a/b?list=Struct”라는 URI는 “./a/b” 노드를 지칭한다. “./a/b” URI역시 “./a/b” 노드를 지칭한다.
DM 서버(120)는 요청할 리소스가 노드 이름이나 노드 값인지 확인한다(S520). 이는 노드 이름과 노드 값 만이 캐시되기 때문이며, 예를 들어, ACL 값에 대한 요청은 로컬 캐시가 존재하지 않는다. 예를 들어, 요청할 리소스가 “./a/b?list=Struct”, “./a/b?list=StructData”, “./a/b”인 경우 노드 이름이나 노드 값에 해당한다. 그러나, 요청할 리소스가 “./a/b?prop=ACL”, “./a/b?prop=Title”인 경우 노드 이름이나 노드 값에 해당하지 않는다.
DM 서버(120)는 요청하려고 하는 리소스를 포함하고 있는 로컬 캐시를 검색한다(S530). 노드 A로부터 루트 노드까지의 모든 노드 중에 어느 하나의 노드라도 캐시를 가지고 있으면 이에 해당 된다.
DM 서버(120)는 제530 단계에서 발견한 캐시의 개수가 여러 개 인지 확인한다(S540).
제540 단계에서 여러 개의 캐시가 발견된 것으로 확인된 경우, DM 서버(120)는 하나의 캐시를 선택한다(S550). 예를 들어, DM 서버(120)는 캐시 생성 시간과 캐시 범위를 기준으로 여러 개의 캐시 중에서 하나의 캐시를 선택할 수 있다.
캐시 생성 시간은 시간 상으로 나중에 생성된 캐시가 캐시 히트가 될 확률이 높고, 캐시 범위는 캐시 범위가 좁은 캐시일수록 캐시 히트의 확률이 높고, 유효성 판단이 더 간단하기 때문이다. 즉 넓은 범위를 포함하는 캐시의 경우, 해당 리소스가 업데이트될 확률이 커서, 캐시 미스의 확률이 높아진다.
로컬 캐시가 존재하는 경우, DM 서버(120)는 캐시를 이용해 리소스를 요청한다. 요청하는 리소스 URI1과, 캐시하고 있는 노드의 URI, 캐시 검증자를 포함하여 요청 메시지를 보낸다. 도 8에서 만약 요청하는 URI1이 “./node2-1?list=StructData”이고, “./node2”에 대한 로컬 캐시를 가지고 있는 경우, (“./node2-1?list=StructData”, “./node2”, CV1)로 리소스를 요청한다. 여기서 CV1은 “./node2”에 대한 캐시 검증자이다. 만약, 요청하는 리소스 URI1이 가리키는 노드가 캐시된 노드와 일치한다면, 캐시된 노드 URI는 생략될 수 있고, DM 서버(120)은 URI1, 캐시 검증자만을 이용하여 URI1을 요청한다.
요청하려는 리소스를 포함하는 로컬 캐시를 가지고 있지 않은 경우, DM 서버(120)는 캐시없이 URI1을 요청한다(S570).
DM 클라이언트로부터의 응답
도 10은 본 발명의 일 실시 예에 따른 DM 클라이언트가 가벼운 리소스 캐싱에 따라 DM 서버에 응답하는 과정을 나타내는 흐름도이다.
DM 클라이언트(110)는 URI1에 대한 요청을 받는다(S610). URI1은 노드 A를 지칭한다. 예로, “./a/b?list=Struct”라는 URI는 “./a/b” 노드를 지칭한다. “./a/b” URI역시 “./a/b” 노드를 지칭한다.
DM 클라이언트(110)는 캐시를 이용한 리소스 요청인지 판단한다. 캐시 검증자를 포함하고 있으면, 캐시를 이용한 리소스 요청이다(S620).
DM 클라이언트(110)는 요청한 리소스가 캐시 가능한 리소스(cacheable resource)인지 확인한다(S630). 노드 이름과 노드 값에 대한 요청이면, 캐시 가능한 리소스에 대한 요청이다.
DM 클라이언트(110)는 DM 서버(120)에 요청한 리소스를 보낸다(S640). 캐시 가능한 리소스가 아니기 때문에, 캐시 검증자를 보낼 필요는 없다.
DM 클라이언트(110)는 DM 서버(120)에 요청한 리소스와 노드 A에 대한 캐시 검증자를 함께 보낸다(S650).
제620 단계에서 캐시를 이용한 리소스 요청인 경우, 요청에는 (URI1, 캐시된 노드 URI, CV1)가 포함되어 있다. 이 경우에, DM 클라이언트(110)는 캐시 히트인지 확인한다(S660). 캐시된 노드 URI에 대해 DM 클라이언트(110)가 저장하고 있는 캐시 검증자와 CV1이 일치하면, DM 클라이언트(110)는 캐시 히트로 판단할 수 있다. 캐시 히트가 아닌 경우, DM 클라이언트(110)는 DM 서버(120)에 요청한 리소스와 노드 A에 대한 캐시 검증자를 함께 보낸다(S650).
제660 단계에서, 캐시 히트인 경우 DM 클라이언트(110)는 노드 A에 대한 캐시인지를 확인한다(S670). 노드 A URI와 요청에 포함되어 있는 캐시된 노드 URI가 일치하면 노드 A에 대한 캐시이다.
제670 단계에서, 노드 A에 대한 캐시 검증자를 가지고 있으면, DM 클라이언트(110)는 “Not Modified”를 DM 서버(120)에게 전송한다(S680).
제670 단계에서, 노드 A에 대한 캐시 검증자를 DM 서버(120)가 가지고 있지 않은 경우에, DM 클라이언트(110)는 DM 클라이언트(110)가 저장하고 있는 노드 A에 대한 캐시 검증자를 DM 서버(120)에게 같이 전송한다(S690).
DM 서버에서의 응답의 처리
이하에서는 DM 서버(120)가 DM 클라이언트(110)로부터 수신한 응답을 처리하는 방법에 대해 설명한다. 도 10에서 DM 클라이언트(110)가 응답하는 단계는 제640 단계, 제650 단계, 제680 단계 및 제690 단계이다.
제640 단계에서, DM 서버(120)의 요청은 캐시 가능하지 않은 리소스에 대한 요청이기 때문에, DM 서버(120)는 별도의 처리 없이 DM 클라이언트(110)로부터 수신한 리소스를 사용한다.
제650 단계에서, DM 클라이언트(110)로부터 리소스와 그에 대응하는 캐시 검증자를 수신하였기 때문에, DM 서버(120)는 전송받은 리소스를 로컬에 캐시한다.
제680 단계에서, DM 서버(120)의 로컬 캐시에 있는 내용이 최신 버전의 리소스이기 때문에, DM 서버(120)는 로컬에 캐시된 리소스를 사용한다.
제690 단계에서, 로컬에 캐시된 리소스가 최신 버전이기 때문에, DM 서버(120)는 캐시된 리소스를 사용하며, 전송받은 캐시 검증자는 노드 A에 대한 캐시 검증자로 저장한다.
캐시 검증자 노드(Cache Validator Node; CV Node)
이상, 가벼운 리소스 캐싱 방법에 대해 설명했다. 가벼운 리소스 캐싱은 노드마다 캐시 검증자를 하나만 두며, 캐시 검증자가 노드 이름과 노드 값 만을 커버하도록 하는 방법이다. 이하에서는 선택된 몇 개의 노드만이 캐시 검증자를 갖는 방법에 대해서 설명한다. 이 방법에 따르면, 모든 노드마다 캐시 검증자를 두지 않으므로, 단말의 오버헤드를 감소시킬 수 있다.
캐시 검증자 노드(CV 노드)란 캐시 검증자가 할당될 수 있는 노드를 말한다. 즉, CV 노드로 지정된 노드만이 캐시 검증자를 가질 수가 있다. 이렇게 CV 노드로 지정될 수 있는 노드는 대표적으로 MO 루트 노드를 들 수가 있다. DevInfo, DevDetail 등과 같이 크기가 작은 MO의 경우, MO 루트 노드만을 CV 노드로 만들어도 충분하다. 하지만 SCOMO와 같은 MO는 크기가 커서, MO 루트 외에도, 추가적으로 “./SCOMO/Download”, “./SCOMO/Inventory/Delivered”, “./SCOMO/Inventory/Deployed”를 CV 노드로 지정할 수 있다. 어떤 노드를 CV 노드로 할당할지는 MO마다 개별적으로 판단한다.
CV 노드 도입의 장점은, 단말이 관리해야 할 캐시 검증자의 개수를 크게 줄일 수 있다는 점이다. DevInfo의 경우, MO 루트를 포함하여 최소 6개의 노드가 있어, 모든 노드에 캐시 검증자를 둘 경우, 총 6개가 필요했지만, CV 노드에 MO 루트만 지정하면 캐시 검증자를 1개로 줄일 수가 있다.
CV 노드를 활용할 경우, 캐시 검증자 업데이트는 도 6, 도 7에서 설명한 업데이트 방식과 기본적으로 동일하다. 다만, CV 노드에 대해서만 캐시 검증자를 업데이트하게 된다. CV 노드가 아닌 노드는 캐시 검증자를 가질 수가 없기 때문이다. 도 6에서 제360 단계 및 제370 단계에서 캐시 검증자 업데이트는 CV 노드에 대해서만 수행된다. 마찬가지로, 도 7에서도 제460 단계 및 제470 단계에서 검증자 업데이트는 CV 노드에 대해서만 수행된다. 또, 리소스 요청 방식은 도 9에서 설명한 리소스 요청 방식과 동일하다. 이는 CV 노드로 지정되지 않는 노드는 캐시 검증자가 없어서, 제530 단계에서 캐시되지 않는 것으로 나타날 뿐이기 때문이다. DM 클라이언트(110)의 응답 방법도 도 10에서 설명한 응답 방식과 기본적으로는 동일하다. 다만, 제650 단계와 제690 단계에서 노드 A에 캐시 검증자를 항상 보내지 않고, 노드 A가 CV 노드일 때만 캐시 검증자를 보낸다. 역시, CV 노드가 아닌 노드는 캐시 검증자를 가질 수가 없기 때문이다.
DM 통지에서 캐싱을 이용한 MO 요청
DM 서버(120)가 DM 클라이언트(110)의 단말관리 필요성이 있을 때, DM 클라이언트(110)에게 DM 통지(Notification)를 보내게 된다. DM 통지를 받은 DM 클라이언트(110)는 DM 서버(120)에게 DM 세션(Session)을 맺어, DM 서버(120)로부터 장치관리를 받게 된다. DM 서버(120)는 DM 통지에 MO 인덱스(Index)를 넣어, 해당 MO를 ‘PKG#1’에서 받을 수가 있다. MO 인덱스는 2 바이트(byte)숫자이며, MOID와 마찬가지로 특정 MO에 대한 식별자로 이용된다. MO 인덱스를 사용하는 이유는 보통 텍스트(plain text)에 기반하는 MOID에 비해, 길이가 짧기 때문이다. 이렇게 DM 통지에서 MO 인덱스를 이용하면, 해당 MO 데이터를 ‘PKG#1’에서 받을 수가 있어, 응답성이 크게 개선되는 효과가 있다.
DM 통지에 MO 인덱스를 넣어, 특정 MO를 ‘PKG#1’에서 요청하는 경우, 다음과 같이 캐싱을 적용할 수가 있다.
DM 서버(120)는 요청하려고 하는 MO의 MO 루트가 CV 노드로 지정되어 있는지 확인한다. MO 루트가 CV 노드일 때, 적용 가능하다. DM 서버(120)가 MO 루트 노드에 대한 캐시 검증자를 가지고 있다면, (MO 인덱스, MO 루트에 대한 캐시 검증자)를 DM 통지에 넣어 DM 클라이언트(110)에게 전송한다. 예로, DevInfo MO의 MO 인덱스가 100이고, DevInfo MO 루트 URI가 “./DevInfo”이고, DM 서버(120)가 가지고 있는 “./DevInfo”의 캐시 검증자가 CV1이라고 하면, DM 서버(120)는 DM 통지에 (100, CV1)을 포함하여 전송한다. DM 클라이언트(110)는 ‘PKG#1’으로 응답을 보낸다.
도 11은 본 발명의 일 실시 예에 따른 DM 클라이언트(110)가 PKG#1으로 응답을 보내는 과정을 나타내는 흐름도이다.
DM 클라이언트(110)는 DM 서버(120)로부터 DM 통지를 받는다(S710). DM 통지에는 MO 인덱스와 MO 루트에 대한 캐시 검증자가 들어 있다고 가정한다. 만약, MO 인덱스가 없거나, MO 인덱스는 있지만, cache 검증자가 들어 있지 않은 경우, DM 1.3의 정의에 따른다.
DM 클라이언트(110)는 DM 트리에서 MO 인덱스로 지칭되는 MO 루트 노드를 검색한다(S720). 먼저, MO 인덱스와 매칭되는 MOID를 얻고, 그 MOID를 가지고 있는 모든 노드를 검색한다. 이때 발견된 노드는 MO 루트 노드이다.
제720 단계에서 발견된 MO 루트 노드가 다수인지 확인한다(S730). 찾은 MO 루트 노드가 다수인 경우, A 타입 또는 B 타입 중 어느 하나의 방식으로 진행될 수 있다. A 방법은 제780 단계로 가며, B 방법은 제 790 단계로 간다.
제720 단계에서 발견된 MO 루트 노드가 1개인 경우, 발견된 MO 루트 노드는 CV 노드이다. 이는 DM 서버(120)가 요청하는 MO의 MO 루트 노드가 CV 노드일 때에만, 캐시 검증자를 보내기 때문이다. DM 클라이언트(110)는 자신이 발견된 MO 루트 노드에 대해 가지고 있는 캐시 검증자와 DM 서버(120)가 보내온 캐시 검증자가 일치하는지 확인한다(S740). 일치하면, DM 클라이언트(110)는 캐시 히트라고 판단한다.
캐시 미스인 경우, DM 클라이언트(110)는 DM 서버(120)가 요청한 MO 데이터를 전송한다(S750). 그리고, DM 클라이언트(110)는 MO 루트 노드에 대한 캐시 검증자를 DM 서버(120)에 추가로 보내준다.
DM 서버(120)가 가지고 있는 로컬 캐시가 최신 버전인 경우, DM클라이언트(110)는 DM 서버(120)에 “Not Modified”를 보낸다(S760).
제770 단계에서는, DM A 타입 또는 B 타입 중 어느 하나의 방식을 선택한다.
A 방식인 경우, 캐시 검증자는 특정 노드에 할당되어 업데이트 되며, 그 특정 노드에 한해서만 의미를 갖는다. 따라서, 캐시 히트 확인을 위해 캐시 검증자를 비교하려면, 비교 대상인 노드가 먼저 정해져야 한다. 하지만 다수의 MO 루트가 발견된 경우, 비교한 MO 루트 노드를 특정할 수 없어, 비교가 곤란하다. 따라서, DM클라이언트(110)는 DM 서버(120)에 “Multiple Found” 메시지를 보낸다(S780).
B 방식에서, 다수의 MO 루트가 발견된 경우, DM 클라이언트(110)는 MO 루트 노드의 캐시 검증자(캐시검증자는 MO 로트 노드가 CV 노드일 경우에만 존재)가 DM 서버(120)가 보내온 캐시 검증자와 일치하는 MO 루트가 있는지 검색한다(S790).
다수의 MO 루트가 발견되었지만, 캐시 히트가 된 MO 루트 노드가 존재하지 않은 경우, DM 클라이언트(110)는 DM 서버(120)에 “Multiple Found, no cache hit”이라는 메시지를 보내고, MO 데이터는 전송하지 않는다(S792). 다수의 MO 데이터 중에서 어느 것을 보내야 할지 알 수 없기 때문이다.
발견된 다수의 MO 루트 노드 중에서, DM 클라이언트(110)는 DM 서버(120)가 보내온 캐시 검증자와 일치하는 캐시 검증자를 갖고 있는 MO 루트 노드에 대한 MO 데이터를 DM 서버(120)에 보낸다. 다수가 발견되었기 때문에, DM 클라이언트(110)는 MO 루트 노드 URI를 추가로 전송하여, 어떤 MO 루트 노드인지 DM 서버(120)에게 알려준다(S794).
대안적인 실시 예들
이하에서는 본 발명의 다른 실시 예들에 대해 설명한다. 지금까지는 RESTful DM에서 인클루시브 캐싱을 이용해 DM 리소스를 캐싱하는 방법에 대해 설명했다. 하지만, RESTful DM은 DM 메시지를 DM 서버(120)와 DM 클라이언트(110)사이에 전달하는 트랜스포트 바인딩의 일종이며, DM 프로토콜의 핵심기능은 아니다. 이는 DM 트랜스포트 바인딩으로 HTTP 바인딩, OBEX 바인딩 등이 사용될 수 있으며, 이 경우 앞서 설명한 RESTful DM의 캐싱이 사용될 수 없기 때문이다. 이하에서는, DM 프로토콜 레벨에서 인클루시브 캐싱을 사용하여, DM 리소스를 캐싱할 수 있는 방법에 대해 설명한다. 이러한 DM 프로토콜 레벨에서의 DM 리소스 캐싱은 트랜스포트 바인딩에 독립적인 캐싱 방법으로서, 트랜스포트 바인딩과 상관없이 DM 리소스 캐싱을 이용할 수 있다는 장점이 있다.
다음의 표 8은 DM 프로토콜 레벨에서 다이렉트 캐시를 이용하여 DM 리소스를 캐싱하는 방법을 보여준다.
표 8
Request 1
<Get><CmdID>4</CmdID><Item><Target><LocURI>./antivirus_data/version</LocURI></Target></Item></Get>
Response 1
<Results><CmdRef>4</CmdRef><CmdID>3</CmdID><Item><Source><LocURI>./antivirus_data/version</LocURI></Source><Data>antivirus-inc/20010522b/5</Data></Item><ETag>686897696a7c876b7e</ETag> <!- cache validator for ./antivirus_data/version --></Results>
Request 2
<Get><CmdID>4</CmdID><Item><Target><LocURI>./antivirus_data/version</LocURI></Target></Item><IfNoneMatch>686897696a7c876b7e </IfNoneMatch></Get>
Response 2
<Results><CmdRef>4</CmdRef><CmdID>3</CmdID><NotModified/></Results>
이하에서는 각각의 단계에 대해 상세히 설명한다. DM 리소스에 대한 요청을 꼭 DM 서버(120)가 할 필요는 없지만, 표 8에서는 DM 서버(120)가 DM 리소스를 요청하는 경우를 가정하였다.
DM 서버(120)가 DM 클라이언트(110)에 DM 리소스 “./antivirus_data/version”에 대해 요청한다(Request 1).
요청 메시지에 캐시 검증자가 포함되어 있지 않기 때문에, DM 클라이언트(110)는 전체 응답(full response)을 한다. DM 클라이언트(110)는 요청에 대한 데이터를 <Item> 요소에 포함하여 DM 서버(120)에게 전송한다. 이때 “./antivirus_data/version”에 대한 캐시 검증자로 ETag를 사용하며, Etag 값을 전달하기 위해 <ETag> 요소를 사용하였다. <ETag> 요소의 사용은 하나의 예이며, 다른 요소를 사용하여도 무방하다(Response 1)..
DMS는 동일 DM 리소스인 “./antivirus_data/version”에 대해 재요청한다. 이때 전에 DM 클라이언트(110)에게서 받은 Etag 값을 같이 전송하며, 이를 위해 <IfNoneMatch>요소를 사용한다(Request 2).
DM 클라이언트(110)는 “./antivirus_data/version”에 대한 캐시 검증자로부터 “./antivirus_data/version”이 변경되었는지 캐시 유효성을 검사한다. DM 클라이언트(110)는 캐시가 유효하다고 판단하면, <NotModified>를 전송해 캐시 히트를 DM 서버(120)에게 알려준다(Response 2).
다음의 표 9는 DM 프로토콜 레벨에서 인클루시브 캐시를 이용하여 DM 리소스를 캐싱하는 방법을 보여준다.
표 9
Request 1
<Get><CmdID>4</CmdID><Item><Target><LocURI>./SCOMO/Download?list=StructData</LocURI></Target></Item></Get>
Response 1
<Results><CmdRef>4</CmdRef><CmdID>3</CmdID><Item><Meta> <Format xmlns=’syncml:metinf’>node</Format> </Meta> <Source> <LocURI>./SCOMO/Download</LocURI> </Source></Item><Item> <Meta> <Format xmlns=’syncml:metinf’>node</Format> </Meta> <Source> <LocURI>./SCOMO/Download/game1</LocURI> </Source> </Item>… The rest of items are here…<ETag>686897696a7c876b7e</ETag> <!- cache validator for ./SCOMO/Download?list=StructData --></Results>
Request 2
<Get><CmdID>4</CmdID><Item><Target><LocURI>./SCOMO/Download/game1?list=StructData</LocURI></Target></Item><InclusiveCacheURI>./SCOMO/Download?list=StructData</InclusiveCacheURI><IfNoneMatch>686897696a7c876b7e</IfNoneMatch></Get>
Response 2
<Results><CmdRef>4</CmdRef><CmdID>3</CmdID><NotModified/><ETag>1231211gea2121fe223</ETag> <!- cache validator for ./SCOMO/Download/game1?list=StructData --></Results>
이하에서는 각각의 단계에 대해 상세히 설명한다. DM 리소스에 대한 요청을 꼭 DM 서버(120)가 할 필요는 없지만, 표 9에서는 DM 서버(120)가 DM 리소스를 요청하는 경우를 가정하였다.
DM 서버(120)는 “./SCOMO/Download?list=StructData”에 대한 DM 리소스를 요청한다(Request 1).
캐시 검증자가 요청 메시지에 포함되어 있지 않기 때문에, DM 클라이언트(110)는 전체 응답(full response)을 한다. DM 클라이언트(110)는 데이터를 <Item> 요소를 통해 DM 서버(120)에 전송하고, “./SCOMO/Download?list=StructData”에 대한 ETag를 같이 전송한다(Response 1).
DM 서버(120)는 “./SCOMO/Download/game1?list=StructData”에 대한 DM 리소스를 요청한다. DM 서버(120)는 이 DM 리소스에 대해 요청한 적이 없기 때문에, 다이렉트 캐시를 가지고 있지 않다. 다만, 이 리소스를 포함하고 있는 “./SCOMO/Download?list=StructData”에 대해 요청한 적이 있기 때문에, 인클루시브 캐시를 가지고 있다. DM 서버(120)는 요청 메시지를 보낼 때, 인클루시브 캐시를 활용하기 위해, 두 가지 정보를 추가로 보내게 된다. 하나는 인클루시브 캐시 검증자이며, <IfNoneMatch> 요소를 이용해 전달된다. 다른 하나는 인클루시브 캐시가 실제 어떤 리소스에 대한 캐시인지를 나타내는 인클루시브 캐시 URI이며 <InclusiveCacheURI>를 통해 전달된다(Request 2).
DMC는 인클루시브 캐시 검증자를 통해, 캐시의 유효성을 검사한 다음, 캐시가 유효하다고 판단되면, <NotModified/> 요소를 보내 캐시 히트를 알린다. 그리고 나중에 다이렉트 캐시를 사용할 수 있도록, “./SCOMO/Download/game1?list=StructData”에 대한 ETag를 전송한다(Response 2).
도 12는 본 발명의 일 실시 예에 따른 단말(200) 및 서버(300)의 블록도이다.
도 12에 도시된 바와 같이 단말(200)은 저장 수단(210)과 컨트롤러(220)와 송수신부(230)를 포함한다. 상기 저장 수단(210)은 도 1 내지 도 11에 도시된 실시 예에 따른 방법을 저장한다. 상기 컨트롤러(220)는 상기 저장 수단(210) 및 상기 송수신부(230)를 제어한다. 구체적으로 상기 컨트롤러(220)는 상기 저장 수단(230)에 저장된 상기 방법들을 각기 실행한다. 그리고 상기 컨트롤러(220)는 상기 송수신부(210)를 통해 상기 전술한 신호들을 전송한다.
또한, 도 12에 도시된 바와 같이 서버(300)는 저장 수단(310)과 컨트롤러(320)와 송수신부(330)를 포함한다. 상기 저장 수단(310)은 도 1 내지 도 12에 도시된 실시 예에 따른 방법을 저장한다. 상기 컨트롤러(320)는 상기 저장 수단(310) 및 상기 송수신부(330)를 제어한다. 구체적으로 상기 컨트롤러(320)는 상기 저장 수단(310)에 저장된 상기 방법들을 각기 실행한다. 그리고 상기 컨트롤러(320)는 상기 송수신부(330)를 통해 상기 전술한 신호들을 전송한다.
이상에서 기술한 실시 예들은 모든 면에서 예시적인 것이며 한정적인 것이 아닌 것으로서 이해해야만 한다. 본 발명의 범위는 상기 상세한 설명보다는 후술하는 특허청구범위에 의하여 나타내어지며, 특허청구범위의 의미 및 범위 그리고 그 등가개념으로부터 도출되는 모든 변경 또는 변형된 형태가 본 발명의 범위에 포함되는 것으로 해석되어야 한다.

Claims (14)

  1. 장치관리 서버가 장치관리 클라이언트로부터 리소스를 획득하는 방법에 있어서,
    제1 리소스에 대한 제1 타입의 캐시 검증자(cache validator)가 존재하는지 판단하는 단계; 여기에서 상기 제1 타입의 캐시 검증자는 상기 제1 리소스를 위해 직접적으로 사용되고,
    상기 제1 리소스에 대한 제1 타입의 캐시 검증자가 존재하지 않는 경우에, 상기 제1 리소스에 대한 제2 타입의 캐시 검증자가 존재하는지 판단하는 단계; 여기에서 상기 제2 타입의 캐시 검증자는 상기 제1 리소스를 포함하는 제2 리소스를 위해 사용되고,
    상기 제1 리소스에 대한 상기 제2 타입의 캐시 검증자가 존재하는 경우에, 상기 제1 리소스에 대한 식별자, 상기 제2 리소스에 대한 식별자 및 상기 제2 리소스에 대한 캐시 검증자를 이용하여 상기 제1 리소스에 대한 요청을 상기 장치관리 클라이언트에 송신하는 단계를 포함하는 것을 특징으로 하는 장치관리 서버의 리소스 획득 방법.
  2. 제1 항에 있어서, 상기 제1 리소스와 연관된 제1 노드 및 상기 제2 리소스와 연관된 제2 노드는 장치관리 트리에 포함되는 것을 특징으로 하는 장치관리 서버의 리소스 획득 방법.
  3. 제2 항에 있어서, 상기 제1 리소스에 대한 제2 타입의 캐시 검증자가 존재하는지 판단하는 단계는,
    현재 노드에서 상기 제1 리소스에 대한 제2 타입의 캐시 검증자를 검색하는 단계;
    상기 현재 노드의 부모 노드를 상기 현재 노드로 설정하는 단계; 및
    상기 제1 리소스에 대한 제2 타입의 캐시 검증자가 처음 발견될 때까지 상기 검색하는 단계 및 상기 설정하는 단계를 반복하는 단계를 포함하고,
    상기 현재 노드는,
    초기에 상기 제1 노드의 부모 노드로 설정되는 것을 특징으로 하는 장치관리 서버의 리소스 획득 방법.
  4. 제2 항에 있어서, 상기 제1 리소스에 대한 제2 타입의 캐시 검증자가 존재하는지 판단하는 단계는,
    상기 제1 노드의 부모 노드부터 상기 장치관리 트리의 루트 노드까지 상기 제1 리소스에 대한 하나 이상의 제2 타입의 캐시 검증자를 검색하는 단계를 포함하는 것을 특징으로 하는 장치관리 서버의 리소스 획득 방법.
  5. 제4 항에 있어서, 상기 제1 리소스에 대한 제2 타입의 캐시 검증자가 존재하는지 판단하는 단계는,
    상기 제1 리소스에 대한 하나 이상의 제2 타입의 캐시 검증자 중에서 상기 제1 리소스에 대한 제2 타입의 캐시 검증자를 선택하는 단계를 포함하는 것을 특징으로 하는 장치관리 서버의 리소스 획득 방법.
  6. 제1 항에 있어서, 상기 제1 리소스 및 제2 리소스는,
    각각 대응하는 식별자에 의해 식별될 수 있는 네트워크 데이터 오브젝트 또는 서비스인 것을 특징으로 하는 장치관리 서버의 리소스 획득 방법.
  7. 제1 항에 있어서, 상기 제1 리소스에 대한 제1 타입의 캐시 검증자가 존재하는 경우에, 상기 제1 리소스에 대한 식별자 및 상기 제1 리소스에 대한 캐시 검증자를 이용하여 상기 장치관리 클라이언트에 상기 제1 리소스에 대한 요청을 송신하는 단계를 더 포함하는 것을 특징으로 하는 장치관리 서버의 리소스 획득 방법.
  8. 제1 항에 있어서, 상기 제1 리소스에 대한 제2 타입의 캐시 검증자가 존재하지 않는 경우에, 상기 제1 리소스에 대한 식별자를 이용하여 상기 장치관리 클라이언트에 상기 제1 리소스에 대한 요청을 송신하는 단계를 더 포함하는 것을 특징으로 하는 장치관리 서버의 리소스 획득 방법.
  9. 장치관리 클라언트가 장치관리 서버에 리소스를 제공하는 방법에 있어서,
    상기 장치관리 서버로부터 제1 리소스에 대한 요청을 수신하는 단계; 여기에서, 상기 요청은 상기 제1 리소스에 대한 제1 타입 또는 제2 타입의 캐시 검증자(cache validator)를 포함하고, 상기 제1 타입의 캐시 검증자는 상기 제1 리소스를 위해 직접적으로 사용되고, 상기 제2 타입의 캐시 검증자는 상기 제1 리소스를 포함하는 제2 리소스를 위해 사용되고,
    상기 요청이 상기 제1 타입의 캐시 검증자를 포함하는 경우에, 상기 제1 타입의 캐시 검증자가 상기 제1 리소스에 대해 유효하면 상기 제1 리소스가 변경되지 않았음을 나타내는 메시지를 상기 장치관리 서버에 송신하는 단계; 및
    상기 요청이 상기 제2 타입의 캐시 검증자를 포함하는 경우에, 상기 제2 타입의 캐시 검증자가 상기 제2 리소스에 대해 유효하면 상기 메시지를 상기 장치관리 서버에 송신하는 단계를 포함하는 것을 특징으로 하는 장치관리 클라이언트의 리소스 제공 방법.
  10. 제9 항에 있어서, 상기 제2 타입의 캐시 검증자가 상기 제2 리소스에 대해 유효하면 상기 메시지를 송신하는 단계는,
    상기 장치관리 클라이언트에 저장된 제1 리소스에 대한 제1 타입의 캐시 검증자가 존재하는 경우, 상기 제1 타입의 캐시 검증자를 이용하여 상기 메시지를 송신하는 단계인 것을 특징으로 하는 장치관리 클라이언트의 리소스 제공 방법.
  11. 제9 항에 있어서, 상기 제1 타입의 캐시 검증자가 상기 제1 리소스에 대해 유효하지 않거나 상기 제2 타입의 캐시 검증자가 상기 제2 리소스에 대해 유효하지 않으면, 상기 제1 리소스를 상기 장치관리 서버에 송신하는 단계를 더 포함하는 것을 특징으로 하는 장치관리 클라이언트의 리소스 제공 방법.
  12. 제11 항에 있어서, 상기 제1 리소스를 송신하는 단계는,
    상기 장치관리 클라이언트에 저장된 제1 리소스에 대한 제1 타입의 캐시 검증자가 존재하는 경우, 상기 제1 타입의 캐시 검증자를 상기 제1 리소스와 함께 송신하는 단계인 것을 특징으로 하는 장치관리 클라이언트의 리소스 제공 방법.
  13. 제9 항에 있어서, 상기 제1 리소스와 연관된 제1 노드 및 상기 제2 리소스와 연관된 제2 노드는 장치관리 트리에 포함된 것을 특징으로 하는 장치관리 클라이언트의 리소스 제공 방법.
  14. 제9 항에 있어서, 상기 제1 리소스 및 제2 리소스는,
    각각 대응하는 식별자에 의해 식별될 수 있는 네트워크 데이터 오브젝트 또는 서비스인 것을 특징으로 하는 장치관리 클라이언트의 리소스 제공 방법.
PCT/KR2012/001897 2011-03-17 2012-03-16 단말의 리소스 제공 방법 및 서버의 리소스 획득 방법 WO2012124999A2 (ko)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US14/005,802 US20140012939A1 (en) 2011-03-17 2012-03-16 Method for providing resources by a terminal, and method for acquiring resources by a server

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US201161453552P 2011-03-17 2011-03-17
US61/453,552 2011-03-17
US201161554975P 2011-11-03 2011-11-03
US61/554,975 2011-11-03

Publications (2)

Publication Number Publication Date
WO2012124999A2 true WO2012124999A2 (ko) 2012-09-20
WO2012124999A3 WO2012124999A3 (ko) 2012-12-27

Family

ID=46831228

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2012/001897 WO2012124999A2 (ko) 2011-03-17 2012-03-16 단말의 리소스 제공 방법 및 서버의 리소스 획득 방법

Country Status (2)

Country Link
US (1) US20140012939A1 (ko)
WO (1) WO2012124999A2 (ko)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2014112781A1 (ko) * 2013-01-18 2014-07-24 엘지전자 주식회사 무선 통신 시스템에서 접근 제어를 위한 방법 및 장치
WO2014163280A1 (ko) * 2013-04-04 2014-10-09 엘지전자 주식회사 무선 통신 시스템에서 서버의 단말의 리소스 요청 또는 단말의 리소스 제공을 위한 방법 및 이를 위한 장치
WO2015034337A1 (ko) * 2013-09-09 2015-03-12 엘지전자 주식회사 무선 통신 시스템에서 특정 요청 메시지의 처리를 위한 방법 및 장치
KR20180082271A (ko) * 2017-01-10 2018-07-18 건국대학교 산학협력단 캐시된 wadl 실행 엔진 및 그를 이용한 웹 서비스 호출 방법

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140136948A1 (en) * 2012-11-09 2014-05-15 Microsoft Corporation Taxonomy Driven Page Model
US10079884B2 (en) * 2016-03-14 2018-09-18 Adobe Systems Incorporated Streaming digital content synchronization
WO2020107342A1 (zh) * 2018-11-29 2020-06-04 华为技术有限公司 分布式系统中追踪业务执行过程的方法和装置

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070038814A1 (en) * 2005-08-10 2007-02-15 International Business Machines Corporation Systems and methods for selectively inclusive cache
KR20090080187A (ko) * 2008-01-21 2009-07-24 한국과학기술원 권한 인증 시스템 및 방법
US20100199122A1 (en) * 2009-02-02 2010-08-05 Arun Sood Cache Validating SCIT DNS Server

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6578113B2 (en) * 1997-06-02 2003-06-10 At&T Corp. Method for cache validation for proxy caches
US7082458B1 (en) * 2001-08-01 2006-07-25 Luigi Guadagno Dialog facilitation system for generating contextual order-preserving dialog postings and posting summaries from electronic messages
US7680875B1 (en) * 2002-04-01 2010-03-16 Novell, Inc. Markers for cached objects
US20040103199A1 (en) * 2002-11-22 2004-05-27 Anthony Chao Method and system for client browser update from a lite cache
US8224964B1 (en) * 2004-06-30 2012-07-17 Google Inc. System and method of accessing a document efficiently through multi-tier web caching
US8073960B2 (en) * 2004-07-01 2011-12-06 Nokia Corporation Arranging management operations in management system
US7921184B2 (en) * 2005-12-30 2011-04-05 Citrix Systems, Inc. System and method for performing flash crowd caching of dynamically generated objects in a data communication network

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070038814A1 (en) * 2005-08-10 2007-02-15 International Business Machines Corporation Systems and methods for selectively inclusive cache
KR20090080187A (ko) * 2008-01-21 2009-07-24 한국과학기술원 권한 인증 시스템 및 방법
US20100199122A1 (en) * 2009-02-02 2010-08-05 Arun Sood Cache Validating SCIT DNS Server

Cited By (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2014112781A1 (ko) * 2013-01-18 2014-07-24 엘지전자 주식회사 무선 통신 시스템에서 접근 제어를 위한 방법 및 장치
US9900727B2 (en) 2013-01-18 2018-02-20 Lg Electronics Inc. Method and apparatus for controlling access in wireless communication system
WO2014163280A1 (ko) * 2013-04-04 2014-10-09 엘지전자 주식회사 무선 통신 시스템에서 서버의 단말의 리소스 요청 또는 단말의 리소스 제공을 위한 방법 및 이를 위한 장치
CN105103505A (zh) * 2013-04-04 2015-11-25 Lg电子株式会社 在无线通信系统中由服务器的终端请求或提供资源的方法和装置
JP2016525728A (ja) * 2013-04-04 2016-08-25 エルジー エレクトロニクス インコーポレイティド 無線通信システムにおけるサーバーの端末のリソース要請又は端末のリソース提供のための方法及びこのための装置
CN105103505B (zh) * 2013-04-04 2018-02-27 Lg电子株式会社 在无线通信系统中由服务器的终端请求或提供资源的方法和装置
US10084748B2 (en) 2013-04-04 2018-09-25 Lg Electronics Inc. Method and apparatus for requesting or providing resource by terminal of server in wireless communication system
WO2015034337A1 (ko) * 2013-09-09 2015-03-12 엘지전자 주식회사 무선 통신 시스템에서 특정 요청 메시지의 처리를 위한 방법 및 장치
US9867164B2 (en) 2013-09-09 2018-01-09 Lg Electronics Inc. Method and device for processing a specific request message in wireless communication system
KR20180082271A (ko) * 2017-01-10 2018-07-18 건국대학교 산학협력단 캐시된 wadl 실행 엔진 및 그를 이용한 웹 서비스 호출 방법
KR101910031B1 (ko) * 2017-01-10 2018-10-19 건국대학교 산학협력단 캐시된 wadl 실행 엔진 및 그를 이용한 웹 서비스 호출 방법

Also Published As

Publication number Publication date
US20140012939A1 (en) 2014-01-09
WO2012124999A3 (ko) 2012-12-27

Similar Documents

Publication Publication Date Title
WO2012124999A2 (ko) 단말의 리소스 제공 방법 및 서버의 리소스 획득 방법
US20230254249A1 (en) Request routing based on class
WO2014010992A1 (ko) 컨텐츠 이름 기반의 컨텐츠 중심 네트워크에서 컨텐츠 및 실시간 스트리밍 컨텐츠 제공을 위한 컨텐츠 요청자 및 컨텐츠 제공자의 통신 방법
EP2214357B1 (en) Method and system for facilitating forwarding a packet in a content-centric network
WO2014081264A1 (en) Method of packet transmission from node and contentowner in content-centric networking
WO2014185754A1 (ko) M2m 통신 시스템에서 구독 및 통지를 위한 방법 및 이를 위한 장치
US7225219B2 (en) Distributed caching architecture for computer networks
WO2016195199A1 (ko) 무선 통신 시스템에서 폴링 채널을 통해 요청을 처리하기 위한 방법 및 이를 위한 장치
KR20050063405A (ko) 온톨로지 기반의 애드혹 서비스 검색 시스템 및 방법
WO2012124985A2 (en) Method and apparatus for synchronizing personal inforamtion
WO2019218441A1 (zh) 请求处理方法、装置、设备及存储介质
WO2016126021A1 (ko) 무선 통신 시스템에서 통지 수신 중단 요청을 처리하기 위한 방법 및 이를 위한 장치
JP2010250799A (ja) リソースの位置情報の要求方法、当該方法のためのユーザノードおよびサーバ
WO2016064235A2 (ko) 무선 통신 시스템에서 그룹 멤버의 자식 자원을 관리하기 위한 방법 및 이를 위한 장치
WO2013047997A1 (ko) 라이트 체크를 기반으로 하는 콘텐트 다운로드 방법, 디바이스 및 시스템
WO2017073876A1 (ko) 무선 통신 시스템에서 서비스 요청을 처리하기 위한 방법 및 이를 위한 장치
CN115883659B (zh) 一种支持cdn缓存批量刷新的方法及装置
WO2018076873A1 (zh) 数据分享方法、装置、介质、电子设备及系统
JP2002525749A (ja) インターネットキャッシングシステム、方法およびそのシステムの構成
CN109644160B (zh) 通过分类在icn中进行名称解析和制作者选择的混合方法
US11323535B2 (en) Management of edge dictionaries in a content delivery network
KR100670818B1 (ko) 분산 구조 라우터에서의 계층2 테이블 관리 방법 및 시스템
WO2017082506A1 (ko) 무선 통신 시스템에서 통지 수신 중단 요청을 처리하기 위한 방법 및 이를 위한 장치
WO2013125920A1 (ko) 로케이션 기반의 언솔리시티드 다운로드 방법, 장치 및 시스템
WO2013066131A2 (ko) 이종 네트워크에서 개인 네트워크 사용정보에 기반한 pn 설정 방법

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 12758313

Country of ref document: EP

Kind code of ref document: A2

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 14005802

Country of ref document: US

122 Ep: pct application non-entry in european phase

Ref document number: 12758313

Country of ref document: EP

Kind code of ref document: A2