WO2014148865A1 - 통합 sns 게이트웨이 - Google Patents

통합 sns 게이트웨이 Download PDF

Info

Publication number
WO2014148865A1
WO2014148865A1 PCT/KR2014/002410 KR2014002410W WO2014148865A1 WO 2014148865 A1 WO2014148865 A1 WO 2014148865A1 KR 2014002410 W KR2014002410 W KR 2014002410W WO 2014148865 A1 WO2014148865 A1 WO 2014148865A1
Authority
WO
WIPO (PCT)
Prior art keywords
server
sns
client
synchronization
protocol
Prior art date
Application number
PCT/KR2014/002410
Other languages
English (en)
French (fr)
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 주식회사 퓨전소프트
Publication of WO2014148865A1 publication Critical patent/WO2014148865A1/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/66—Arrangements for connecting between networks having differing types of switching systems, e.g. gateways
    • 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/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1095—Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0281—Proxies
    • 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
    • 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

Definitions

  • the present invention relates to an integrated SNS gateway connecting one or more content servers and a mobile terminal.
  • SNS social networking service
  • SNS applications based on the push method has a very large difference in the nature of providing the users are using a number of SNS applications, each SNS application to access the SNS server individually to update the information in a 1: 1 communication method.
  • the 1: 1 communication method has a problem such that traffic is concentrated and response speed is slowed down as the number of users increases.
  • This communication method is similar to the initial web or FTP that communicated in a 1: 1 manner.
  • the web has introduced a method for increasing the response speed of the web and reducing traffic.
  • the most representative example is web caching.
  • SNS can improve communication performance by placing any device in between.
  • the communication protocol of each SNS is not a communication protocol according to the standard, it is difficult to apply the above method because each SNS uses a different self communication protocol.
  • the present invention proposes an application gateway method for improving communication performance of SNS.
  • An embodiment of the present invention communicates with one or more SNS servers in a separate protocol, and communicates with a client through an integrated SNS protocol, and performs an synchronization or caching function in the process to reduce traffic and improve response speed. I would like to propose.
  • the integrated SNS gateway of the present embodiment communicates with at least one client connected to a network through an integrated SNS protocol, receives a message and ID information of the client from the broker server, and relays the message transfer between the plurality of SNS servers.
  • An account manager managing an account of the data manager, a data manager receiving ID approval and a message request of the account manager, a data manager managing data of a cache server and a synchronization server, a synchronization server performing a synchronization function according to a command of the data manager;
  • a cache server for caching functions according to the command of the data manager, and a web service adapter for receiving commands from the synchronization server and the cache server and communicating with each SNS server according to a separate protocol.
  • a synchronization function and a caching function are performed in the middle of communication between the client and the SNS server, thereby reducing traffic and improving response speed.
  • FIG. 1 is a diagram schematically illustrating communication between a client, a gateway, and an SNS server according to an embodiment of the present invention.
  • FIG. 2 is a diagram schematically illustrating a configuration of a gateway according to an embodiment of the present invention.
  • 3 is an object tree for each content of each SNS server according to an embodiment of the present invention.
  • FIG. 4 is a server sequential diagram showing an operation process between each component of a gateway according to an embodiment of the present invention.
  • FIG. 5 is a flowchart illustrating an operation process between components of a gateway server while updating data in an integrated application according to an embodiment of the present invention.
  • FIG. 6 is a sequential diagram of a synchronization method using SyncML according to an embodiment of the present invention.
  • FIG. 7 illustrates a configuration of a topic tree according to an embodiment of the present invention.
  • Qos quality of service
  • FIG 9 illustrates a message delivery process of an MQTT according to an embodiment of the present invention.
  • FIG 10 illustrates an actual network experiment configuration for the design of the integrated SNS protocol according to an embodiment of the present invention.
  • FIG. 11 shows an analysis result of the average end-to-end delay of the experiment of FIG. 10.
  • FIG. 1 is a diagram schematically illustrating communication between a client 10, a gateway 1, and a network server according to an exemplary embodiment of the present invention.
  • the present embodiment includes a client 10 communicating with the gateway 1 through an integrated protocol, a gateway 1 improving communication performance at an intermediate position between the client 10 and the SNS server 5.
  • the SNS server 5 communicates with the gateway 1 in a respective protocol manner.
  • the client 10 may be configured as a portable terminal, and the terminal is provided with an integrated SNS application, thereby communicating with the gateway 1 through the integrated SNS protocol.
  • the integrated SNS application is to provide a function provided by each existing SNS application in one application.
  • the integrated SNS protocol is based on the communication method of the push notification service method, and the MQTT (Message Queuing Telemetry Transport) protocol, which is an open protocol announced by IBM, is used, but it is obvious that other protocol methods can be used.
  • MQTT is composed of broker server 101, Publish client and Subscribe client. Detailed design will be described later.
  • the SNS servers 5 communicate with the client 10 through the gateway 1 in a respective protocol manner.
  • the SNS servers 5 use different self-communication protocols for each SNS, and most SNS servers 5 do not disclose protocol protocols, but can analyze the protocols by a protocol reverse engineering method.
  • facebook's protocol is based on the HTTP protocol by protocol reverse engineering.
  • the gateway 1 communicates with the integrated SNS application of the client 10 by the integrated SNS protocol method, and communicates with the SNS server 5 by the self-protocol method of the SNS server 5 to communicate between different protocols. It is possible to perform the synchronization, caching, integrated authentication function at the location of the communication between the client 10 and the SNS server (5).
  • the gateway 1 stores user information, stores or provides data at the request of the integrated SNS application, accesses the SNS server 5 directly, updates the user's SNS information, and obtains the latest information. Provide to the application.
  • the gateway 1 also performs account management and security processing functions in accordance with multiple user connections. The user accesses the SNS periodically using the user account information to update the information and obtain the latest information.
  • the gateway 1 minimizes the load of the integrated SNS application and improves communication performance through a cache function for periodically storing data on the SNS periodically using a user account information and a synchronization function for transmitting only changed data. To communicate.
  • the cache function and the synchronization function are mainly referred to, and the account management or security function is minimally mentioned in the range that does not cause technical content delivery.
  • the synchronization function is a method for maintaining the same data between devices or programs at different locations. This feature is an improvement over updating all data without considering differences to keep the same data.
  • the gateway 1 and the SNS server 5 communicate with each other in the conventional manner to maintain the latest information, and the latest information is compared with the existing information to calculate the changed information. Only changed information can be delivered to integrated SNS application to increase traffic and response speed.
  • the contents transmitted to the integrated SNS application are copied and stored. If the same contents are subsequently requested by the SNS application, the SNS server 5 immediately sends the stored data without receiving the data. .
  • This approach is the same as traditional Internet caching, which reduces the load on the SNS server 5, reduces the traffic volume, and reduces the response time.
  • a method for identifying whether the same data is provided for the object provided to the SNS should be introduced.
  • URLs play this role.
  • the lifetime of the object is transmitted and used in the HTTP protocol.
  • the gateway 1 of the present invention can also provide and utilize the existing web caching function.
  • the existing web caching result must be converted into integrated protocol and provided. Since a lot of SNS data already contains multimedia data such as photos and videos, this web caching function will be less effective.
  • caching is possible for objects that can be cached based on the results of SNS protocol analysis along with the use of existing web caching functions. For example, when the existing SNS server 5 uploads a picture to its own server, the result is sent back to complete its own page.
  • the integrated authentication function is to integrate the authentication to one or more SNS server (5) individually, to replace the high-level authentication by gathering the authentication required from multiple terminals into one.
  • the gateway 1 also performs account management and security processing according to multiple user accesses.
  • FIG. 2 is a diagram schematically showing the configuration of a gateway 1 according to an embodiment of the present invention.
  • the gateway 1 of this embodiment is a broker server (broker Server) 101 that relays message transmission between the client 10 and the SNS server 5, and a security that protects information of the client 10.
  • a data manager that manages data such as a manager (Security Manager) 102, an account manager (103) managing an account of the client 10, a cache server 106, a synchronization server 105, and the like.
  • 104 a synchronization server (Synchronization Server 105) responsible for the synchronization function, a cache server (Cache Sever, 106) responsible for the caching function, and can be individually connected according to the protocol of each SNS server (5). It consists of a Web Service Adapter (107).
  • the broker server 101 refers to the SNS server 5 and 5 as the publish client and the client 10 as the subscribe client
  • the publish client and the subscribe client transmit messages to each other. It plays a role of relaying between them in the middle.
  • the push-based communication between the integrated SNS application and the gateway 1 uses the MQTT protocol developed as an open source project
  • the broker server 101 uses Mosquitto, but is not limited thereto. Do.
  • security manager provides a security function, account management function, data management function, respectively.
  • Each function is a component developed according to the detailed functions defined by itself in order to operate as the gateway 1.
  • the cache server 106 copies and stores the contents transmitted to the integrated SNS application. If the same contents are subsequently requested by the SNS application, the cache server 106 does not receive the data from the SNS server 5 and immediately stores the stored data. send.
  • the cache server 106 may use the Squid cache server 106 developed as an open source project.
  • Squid server is a server for cache and proxy.
  • the web caching function can be used as a base, and the function of the Squid server can be used.
  • it is possible to improve the caching in the SNS protocol by improving the portion of the Squid cache server 106 to determine whether to cache.
  • the synchronization server 105 is a method for maintaining the same data between devices or programs located at different locations, and in the embodiment of the present invention, only the portions changed between the client 10 and the SNS server 5 are exchanged. Receiving receiving
  • the synchronization server 105 may utilize a Funambol synchronization engine developed as an open source project.
  • the Funambol synchronization engine was developed based on the SyncML protocol, a synchronization standard protocol.
  • the engine provides a way to develop adapters separately for objects for synchronization.
  • the gateway 1 has been improved to construct an object tree for SNS objects and to calculate changed information based on the tree.
  • FIG 3 illustrates an object tree for each content of each SNS server 5 according to an embodiment of the present invention.
  • a tree may be constructed using an extension of a content type (for example, image, text, flash, and video) as one object.
  • a content type for example, image, text, flash, and video
  • the web service adapter 107 allows the gateway 1 to access each SNS server 5 using a unique protocol used for each SNS service.
  • the web service adapter 107 must be developed for each SNS and each SNS. Develop using the development platform provided by.
  • Facebook's web service adapter 107 is a Facebook SDK provided by Facebook.
  • FIG. 4 is a server sequential diagram showing an operation process between each component of the gateway 1 according to an embodiment of the present invention
  • FIG. 5 is a diagram illustrating a gateway (while updating data in an integrated application according to an embodiment of the present invention). 1) It is a flowchart showing the operation process between each component of the server.
  • the client 10 requests a page to the broker server 101 through the MQTT protocol using the integrated SNS application (S501).
  • the broker server 101 matches the page requested by the client 10 with the SNS server 5 corresponding to the page, requests the account manager 103 to authenticate the client 10, and the page of the client 10. Send a request. (S502)
  • the account manager 103 checks the ID of the client 10 for the client 10 authentication (S503), and if the ID of the client 10 is not authenticated again, the client 10 through the broker server 101 again. Send a reject message according to the authentication failure.
  • a request for the page is sent to the data manager 104.
  • the data manager 104 checks whether there is content for the client 10 request page in the cache server 106 (S505).
  • the cache server 106 transmits the content to the data manager 104 (S506), and the data manager transmits the content to the broker server 101 (S510).
  • the broker server 101 responds to the client 10 according to the page request (S511).
  • the cache server 106 requests the page to the SNS server through the web service adapter 107.
  • the web service adapter 107 corresponds to the SNS corresponding to the page request.
  • the page is requested by the protocol of the server 5 and a response to the request is received (S508).
  • the web service adapter 107 stores the content corresponding to the response in the cache server 106 and transmits the content to the data manager 104 (S509).
  • the data manager 104 transmits the content to the broker server 101 (S510), and the broker server 101 transmits a content response according to the page request to the client 10 (S511).
  • the client 10 caches content that is frequently requested, since the content is provided to the client 10 in the gateway 1 server without reaching the actual SNS server 5, traffic and response time can be reduced.
  • FIG. 6 is a sequential diagram of a synchronization method using SyncML according to an embodiment of the present invention.
  • the SNS server 5 transmits a push message and data of the updated content to the protocol of the SNS server 5.
  • the web server adapter receives the updated data to the adapter of the SNS server (5).
  • the synchronization engine checks whether there is changed data among the received data, and transmits only the changed data to the synchronization server 105.
  • the synchronization engine repeats the above process while the SNS server 5 transmits data.
  • the synchronization server 105 updates the received data and finishes synchronization.
  • the synchronization server 105 may improve the response speed and traffic performance by transmitting only the changed portion to match the data of the SNS server 5.
  • One embodiment of the present invention designs an integrated SNS protocol based on MQTT. However, it is not limited thereto.
  • MQTT basically consists of one broker server 101, two Publish clients, and Subscribe clients.
  • the SNS server 5 will be represented as a publsh client 801 and the client 10 as a Subscribe client 802.
  • the SNS server 5 may be a subscribe client
  • the client 10 may be a publsh client.
  • the broker server 101 acts as a relay for message delivery for a topic given between two publish and subscribe clients.
  • the Publish client publishes a topic and forwards the message to the broker server 101, the Subscribe client subscribes to the topic of interest.
  • MQTT-based protocol design must define three things as follows. The first is the Topic Tree of the message to be delivered, the second is the QoS level, and the third is the length of the message.
  • FIG. 7 illustrates a configuration of a topic tree according to an embodiment of the present invention.
  • MQTT uses Topic for push service between Publish / Subscribe client and Broker server.
  • Topic tree is used to manage the topic by further subdividing each topic.
  • the broker server 101 sees the topic of the Publish client and sends messages only to the Subscribe clients that have requested a subscription. Will be sent.
  • Qos quality of service
  • Qos refers to the quality of service related to transmission rate and error rate on the Internet or network.
  • MQTT supports three levels of QoS to guarantee the reliability of messaging.
  • qos 0 700 delivers a message only once and does not check whether it is delivered. Therefore, in the case of a message having a large payload, if a packet loss occurs, the message is likely to be lost without being delivered.
  • qos 1 701 delivers the message at least once and checks whether it is delivered. However, if the PUBACK packet is lost, there is a possibility that the message is redundantly delivered.
  • qos 2 702 delivers exactly once through a 4-way handshake. If you use qos 2 (702), there is no possibility of losing the message, but the end-to-end delay is increased by the 4-way handshake process. The higher the QoS level, the greater the end-to-end delay as packets are exchanged more often.
  • the retransmission time is the transport protocol. It is a good idea to use a high QoS level to ensure that the message is delivered from the Publish client to the Subscribe client. In this case, however, the end-to-end delay increases. If the results of packet loss and end-to-end delay on payload size can be analyzed to derive the appropriate QoS level according to payload size, it will be able to construct a more effective push notification service network environment using MQTT. .
  • the experimental environment and measuring method for determining the QoS level and message length will be described, and the second will be presented to design the integrated SNS protocol by presenting the experimental result and the decision derived based on this.
  • FIG 9 illustrates a message delivery process of an MQTT according to an embodiment of the present invention.
  • FIG 10 shows an actual network experiment configuration for the design of the integrated SNS protocol according to an embodiment of the present invention.
  • the server OS for the experiment is CentOS 6.3 Final in Linux, and the broker server 101 software can use Mosquitto, an open source project.
  • MQTT delivers messages through a broker server 101 between a Publish client and a Subscribe client.
  • 9 shows a process in which each client delivers a message to a corresponding topic through the broker server 101.
  • the publish client informs the broker server 101 of the topic to publish.
  • the broker server 101 plays a role of relaying messages between clients based on the corresponding topic when the publishing topic of the publishing client and the subscribe client subscribe to the same topic.
  • the Subscribe client receives the message only for the Topic that made the Subscribe request to the broker server 101.
  • a Publish client delivers a Topic named A to the broker server 101, and a number of Subscribe Clients request to subscribe to a Topic named A, only the Subscribe client that requested to subscribe to A Topic, You will receive a message.
  • a communication environment between the client 10 and the gateway 1 may be implemented as shown in FIG. 10 for an experiment in an environment similar to an actual network.
  • the portable terminal communicates with the broker server 101 via a 3G network, which is the same as an experiment in an actual wireless network environment.
  • the experiment was conducted in JAVA language based client 10 using IA92 library in Android 2.3 environment.
  • the maximum transmission unit (MTU) of the test target device is set to 1,500.
  • a Shark application is used to collect packets.
  • packet capture is done through Shark application and packet analysis is performed with Wireshark.
  • Packets between the server and client 10 are collected for 5 minutes of measurement time to analyze end-to-end delay and packet loss.
  • End-to-end delay measurements are measured using timestamps from the Publish client to the Subscribe client past the gateway (1) server.
  • the packet loss measuring method counts and measures retransmission request packets of packets measured for 5 minutes.
  • FIG. 11 is a diagram illustrating an analysis result of an average end-to-end delay of the experiment of FIG. 10, and FIG. 12 is a diagram illustrating an analysis result of packet loss of the experiment of FIG. 10.
  • the payload size grows significantly from 4,000. In the case of qos 0 (700), it decreased rather from 4,000 to 0.65 to 0.61, while qos 1 (701) was maintained at 0.57 and QoS was 0.47, which is the same value as the payload length is 1,000. However, starting at 4,000 payloads, the propagation delay increased by at least 0.15 at all QoS levels.
  • the propagation delay is not high for each QoS.
  • the QoS level does not need to be considered in terms of propagation delay, and the payload size should be less than 4,000.
  • a communication performance improvement method using the gateway 1 is proposed. It was possible to confirm the upper design result of the gateway 1 to the higher design result of the gateway 1 to realize the proposed scheme, and also to design the MQTT-based SNS integrated protocol for communication between the gateway 1 server and the terminal. I could confirm it.
  • the gateway 1 of the embodiment plays a role of caching and synchronization, it is possible to improve communication performance in comparison with the existing.
  • the SNS integration protocol can be operated based on the MQTT, and it is possible to obtain a reliable result with respect to the performance of the MQTT.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

본 실시예의 통합 SNS 게이트웨이는, 네트워크 연결된 적어도 하나 이상의 클라이언트와 통합 SNS 프로토콜로 통신하고, 복수의 SNS 서버간의 메시지 전달을 중계하는 브로커 서버와, 상기 브로커 서버로부터 클라이언트의 메시지와 ID 정보를 받고, 클라이언트의 계정을 관리하는 계정관리자와, 상기 계정관리자의 ID 승인 및 메시지 요청을 받고, 캐시 서버와 동기화 서버의 데이터를 관리하는 데이터 관리자와, 상기 데이터 관리자의 명령에 따라 동기화 기능을 담당하는 동기화 서버와, 상기 데이터 관리자의 명령에 따라 캐싱 기능을 담당하는 캐시 서버와, 상기 동기화 서버와 상기 캐시 서버의 명령을 수신하고, 각각의 SNS 서버와 개별적인 프로토콜에 따라 통신을 수행하는 웹 서비스 어댑터를 포함한다.

Description

통합 SNS 게이트웨이
본 발명은 하나 이상의 콘텐츠 서버와 모바일 단말기를 연결하는 통합 SNS 게이트웨이에 관한 것이다.
스마트 기기 사용이 급증함에 따라, 모바일 트래픽도 기하급수적으로 증가하고 있다. 특히 모바일 트래픽 중 SNS(Social Networking Service) 트래픽이 급격히 증가하고 있다.
증가하는 SNS 트래픽에 대응하기 위한 방법으로 현재 많은 모바일 SNS 어플리케이션들은 푸시방식으로 동작하고 있다.
푸시방식에 기초한 SNS 어플리케이션들은 제공하는 성격이 매우 큰 차이가 있어서 사용자들은 여러 개의 SNS 어플리케이션을 사용하고 있고, 각 SNS 어플리케이션은 SNS 서버에 개별적으로 접근하여 1:1 통신 방식으로 정보를 갱신한다. 이러한 1:1 통신 방법은 사용자가 증가함에 따라 트래픽이 집중되고 응답속도가 느려지는 등의 문제점이 있다.
이와 같은 통신 방식은 1:1 방식으로 통신하던 초기 웹이나 FTP와 유사한데, 웹은 사용이 증가함에 따라서 웹의 응답 속도를 높이고 트래픽을 줄이기 위한 방법을 도입하였으며, 가장 대표적인 예로 웹 캐싱이 있다. 사용자 트래픽이 모이는 지점에 웹 캐싱 장치를 설치하여 웹서버로부터 이미 가져온 정보를 빠르게 사용자에게 제공함으로써 응답시간과 트래픽을 줄일 수 있었다.
SNS도 이와 같이 중간에 어떤 장치 두고 통신성능을 개선할 수 있으나, 각 SNS의 통신 프로토콜이 표준에 의한 통신 프로토콜이 아니라서 각 SNS별로 다른 자가 통신 프로토콜을 사용하고 있어서 위 방법을 적용하기 힘들다.
그러므로 본 발명은 SNS의 통신성능 개선을 위해서 어플리케이션 게이트웨이 방식을 제안한다.
본 발명의 실시예는 하나 이상의 SNS 서버와 개별적인 프로토콜로 통신하고, 클라이언트와는 통합 SNS 프로토콜로 통신하며, 그 과정에서 동기화 기능이나 캐싱기능을 수행하여 트래픽을 감소시키고 응답속도를 향상시키는 통합 SNS 게이트웨이를 제안하고자 한다.
본 실시예의 통합 SNS 게이트웨이는, 네트워크 연결된 적어도 하나 이상의 클라이언트와 통합 SNS 프로토콜로 통신하고, 복수의 SNS 서버간의 메시지 전달을 중계하는 브로커 서버와, 상기 브로커 서버로부터 클라이언트의 메시지와 ID 정보를 받고, 클라이언트의 계정을 관리하는 계정관리자와, 상기 계정관리자의 ID 승인 및 메시지 요청을 받고, 캐시 서버와 동기화 서버의 데이터를 관리하는 데이터 관리자와, 상기 데이터 관리자의 명령에 따라 동기화 기능을 담당하는 동기화 서버와, 상기 데이터 관리자의 명령에 따라 캐싱 기능을 담당하는 캐시 서버와, 상기 동기화 서버와 상기 캐시 서버의 명령을 수신하고, 각각의 SNS 서버와 개별적인 프로토콜에 따라 통신을 수행하는 웹 서비스 어댑터를 포함한다.
제안되는 본 발명의 실시예의 통합 SNS 게이트웨이에 의해서 클라이언트와 SNS 서버와의 통신 중간에서 동기화 기능과 캐싱기능을 수행하여 트래픽을 감소시키고 응답속도를 향상시키는 장점이 있다.
도 1은 본 발명의 일 실시 예에 따른 클라이언트와, 게이트웨이와, SNS 서버의 통신을 개략적으로 보여주는 도면이다.
도 2는 본 발명의 일 실시 예에 따른 게이트웨이의 구성을 개략적으로 보여주는 도면이다.
도 3은 본 발명의 일 실시 예에 따라 각 SNS 서버의 콘텐츠별로 객체 트리를 구성한 것이다.
도 4는 본 발명의 일 실시 예에 따라 게이트웨이의 각 구성요소 간의 동작 과정을 나타내는 서버 순차 다이어그램이다.
도 5는 본 발명의 일 실시 예에 따라 통합 어플리케이션에서 데이터를 갱신하는 동안 게이트웨이 서버의 각 구성요소 간의 동작 과정을 나타내는 순서도이다.
도 6은 본 발명의 일 실시 예에 따라 SyncML 이용한 동기화 방법의 순차다이어그램을 나타낸다.
도 7은 본 발명의 일 실시 예에 따라 Topic tree의 구성을 나타낸다.
도 8은 Qos(Quality of Service) 레벨에 따른 패킷 교환 방법을 나타낸다.
도 9는 본 발명의 일 실시 예에 따라 MQTT의 메시지 전달과정을 나타낸다.
도 10은 본 발명의 일 실시 예에 따라 통합 SNS 프로토콜의 설계를 위한 실제 네트워크 실험 구성을 나타낸다.
도 11은 도 10의 실험의 평균 종단 간 지연의 분석결과를 나타낸다.
도 12는 도 10의 실험의 패킷 손실의 분석 결과를 나타낸다.
이하에서는, 본 실시예에 대하여 첨부되는 도면을 참조하여 상세하게 살펴보도록 한다. 다만, 본 실시예가 개시하는 사항으로부터 본 실시예가 갖는 발명의 사상의 범위가 정해질 수 있을 것이며, 본 실시예가 갖는 발명의 사상은 제안되는 실시예에 대하여 구성요소의 추가, 삭제, 변경 등의 실시변형을 포함한다고 할 것이다.
도 1은 본 발명의 일 실시예에 따른 클라이언트(10)와 게이트웨이(1)와, 네트워크 서버의 통신을 개략적으로 보여주는 도면이다.
도 1을 참조하면, 본 실시예는 게이트웨이(1)와 통합 프로토콜로 통신하는 클라이언트(10)와, 상기 클라이언트(10)와 SNS 서버(5) 중간 위치에서 통신 성능을 개선하는 게이트웨이(1)와, 각자의 프로토콜 방식으로 게이트웨이(1)와 통신하는 SNS 서버(5)로 구성되어있다.
이들 구성에 대하여 상세히 살펴보면 다음과 같다.
상기 클라이언트(10)는 휴대용 단말기로 구성될 수 있고, 당해 단말기에는 통합 SNS 어플리케이션이 설치되어있어, 이를 통하여 게이트웨이(1)와 통합 SNS 프로토콜로 통신한다.
상기 통합 SNS 어플리케이션은 기존의 각각의 SNS 어플리케이션이 제공하는 기능을 하나의 어플리케이션에서 제공하는 것이다.
본 발명의 실시예에서는 통합 SNS 프로토콜로 푸시 알림 서비스 방식의 통신방식에 기초하고 있으며, IBM에서 발표한 오픈 프로토콜인 MQTT(Message Queuing Telemetry Transport) 프로토콜을 사용하였으나, 다른 프로토콜 방식의 사용이 가능함은 당연하다. MQTT는 브로커 서버(101)와, Publish 클라이언트와, Subscribe 클라이언트로 구성되어 있으며, 세부적인 설계는 뒤에서 설명한다.
또한, SNS 서버(5)들은 각자의 프로토콜 방식으로 게이트웨이(1)를 통해 클라이언트(10)와 통신한다.
현재 SNS 서버(5)들은 SNS 별로 다른 자가 통신 프로토콜을 사용하고 있으며, 대부분의 SNS 서버(5)는 프로토콜 규약을 공개하고 있지 않으나, 프로토콜 역 공학 방법 등에 의하여 프로토콜을 분석할 수 있다.
예를 들어, facebook의 프로토콜은 프로토콜 역공학 방법에 의하여 HTTP 프로토콜을 기반으로 만들어져 있음을 알 수 있다.
또한, 게이트웨이(1)는 상기 클라이언트(10)의 통합 SNS 어플리케이션과 통합 SNS 프로토콜 방식으로 통신하고, 상기 SNS 서버(5)와는 SNS 서버(5)의 자가 프로토콜 방식으로 통신하여 서로 다른 프로토콜 사이의 통신을 가능하게 하며, 클라이언트(10)와 SNS 서버(5)의 통신 중간의 위치에서 동기화, 캐싱, 통합인증기능을 수행한다.
상세히 설명하면, 게이트웨이(1)는 사용자 정보를 저장하고 통합 SNS 어플리케이션의 요청에 의해 데이터를 저장하거나 제공하며 SNS 서버(5)에 직접 접근하여 사용자의 SNS 정보를 갱신하고 최신 정보를 가져와서 통합 SNS 어플리케이션에 제공한다. 이 게이트웨이(1)는 다수 사용자 접속에 따른 계정관리 및 보안처리 기능도 수행한다. 사용자 계정 정보를 이용하여 주기적으로 SNS에 접근을 하여 정보를 갱신하고 최근 정보를 입수한다.
이 과정에서 게이트웨이(1)는 사용자 계정 정보를 이용하여 주기적으로 SNS에 대한 데이터를 임시 저장하는 캐시기능과, 변경된 데이터만을 전송하는 동기화를 기능을 통하여 통합 SNS 어플리케이션의 부하를 최소화하고 통신성능을 향상시키도록 통신을 한다.
본 발명의 실시 예에서는 이후로 통신성능 향상에 관하여만 다루기 때문에 캐시 기능과 동기화 기능에 대하여 주로 언급하고 기술적인 내용 전달에 지장을 초래하지 않는 범위에서 계정관리나 보안기능에 대하여는 최소로 언급한다.
상기 동기화 기능은 서로 다른 위치에 있는 장치 또는 프로그램 간에 동일한 데이터를 유지하기 위한 방법으로 서로 변경된 부분만을 주고받는 받는 것이다. 이 기능은 동일한 데이터를 유지하기 위해서 차이점을 고려하지 않고 모든 데이터를 갱신하는 방법보다 개선된 방법이다.
예를 들면, 기존의 Facebook의 통신의 경우 서버에 접속을 하면 친구리스트를 모두 다시 갱신한다. 그러나 동기화 기능을 활용하면 기존의 친구리스트에서 변화된 부분만을 전송하여 일치시킴으로 응답속도와 트래픽 성능을 향상시킨다.
즉, 게이트웨이(1)와 SNS 서버(5) 사이에는 기존의 방식대로 통신을 하여 최근 정보를 유지하며, 최근 정보는 기존의 정보와 비교하여 변화된 정보를 계산한다. 변경된 정보만을 통합 SNS 어플리케이션에게 전달하여 트래픽과 응답속도를 높일 수 있다.
동기화할 때, 각 SNS 서버(5)별로 동기화 기능으로 성능을 향상시킬 수 있는 정보를 정의하고 동기화 객체를 객체트리로 구성하면 동기화 영역을 쉽게 계산할 수 있다.
상기 캐싱기능에 대하여 설명하면, 통합 SNS 어플리케이션에 전송한 내용을 복사하여 저장하고 있다가, 이후에 SNS 어플리케이션에서 동일한 내용을 요청하면 SNS 서버(5)에서 데이터를 받아 오지 않고 저장된 데이터를 곧 바로 보낸다.
이 방식은 전통적인 인터넷 캐싱과 동일하며 SNS 서버(5)의 부하를 줄이고 트래픽의 양을 줄이고 응답시간을 줄여준다. 이 방법이 SNS 게이트웨이(1)에서 가능하기 위해서는 SNS로 제공되는 객체에 대하여 동일한 데이터인지를 식별할 수 있는 방법이 도입되어야 한다. 웹의 경우 웹 객체별로 URL이 바로 이러한 역할을 한다. 또한 각 객체에 대하여 객체의 일정시간 동안의 유효성을 계산할 수 있어야 한다. 웹의 경우 HTTP 프로토콜에서 객체의 수명이 전달되며 이를 사용하고 있다.
위에서 설명했듯이, Facebook의 프로토콜은 HTTP 프로토콜을 기반으로 만들어져 있다. 따라서 휴대용 단말기에서도 기본적으로 기존의 웹캐싱장치를 사용하여도 통신성능 향상의 효과가 있다. 따라서 본 발명의 게이트웨이(1)도 기존의 웹캐싱기능을 제공 활용할 수 있다. 다만 통합 SNS 어플리케이션에게 제공하기 위해서는 기존의 웹캐싱 결과를 통합 프로토콜로 변환하여 제공해야한다. 이미 많은 SNS 데이터에 사진, 동영상 등 멀티미디어 데이터가 포함되어 있기 때문에 이 웹캐싱 기능은 효과가 적지 않을 것이다.
또한, 기존 웹캐싱 기능 활용과 함께 SNS 프로토콜 분석결과를 기반으로 캐싱 가능한 객체에 대하여 캐싱이 가능하다. 예를 들면 기존 SNS 서버(5)는 사진을 자신의 서버에 올리면 결과를 다시 전송받아서 자신의 페이지를 완성한다.
이러한 방식은 사진을 올리고 다시 내려 받는 결과를 초래해 불필요한 트래픽을 유발하며 게이트웨이(1)는 이 불필요한 트래픽을 절감한다.
상기 통합인증기능은 하나 이상의 SNS 서버(5)에 개별적으로 인증을 하는 것을 통합하여, 여러 개의 단말에서 요구되는 인증을 하나로 모아서 높은 수준의 인증을 대신하는 것이다. 이 과정에서 게이트웨이(1)는 다수 사용자 접속에 따른 계정관리 및 보안처리 기능도 수행한다.
도 2는 본 발명의 일 실시예에 따른 게이트웨이(1)의 구성을 개략적으로 보여주는 도면이다.
도 2를 참조하면, 본 실시예의 게이트웨이(1)는 클라이언트(10)와 SNS 서버(5)간의 메시지 전달을 중계하는 브로커 서버(브로커 Server,101)와, 클라이언트(10)의 정보를 보호하는 보안 관리자(Security Manager,102)와, 클라이언트(10)의 계정을 관리하는 계정관리자(Account Manager,103)와, 캐시 서버(106)와 동기화 서버(105)등의 데이터를 관리하는 데이터 관리자(Data Manager,104)와, 동기화 기능을 담당하는 동기화 서버(Synchronization Server,105)와, 캐싱 기능을 담당하는 캐시 서버(Cache Sever,106)와, 각 SNS 서버(5)의 프로토콜에 따라 개별적으로 접속할 수 있게 하는 웹 서비스 어댑터(Web Service Adaptor,107)로 구성되어 있다.
이들 구성에 대해서 간략히 설명하면, 상기 브로커 서버(101)는 SNS 서버(5)(5)를 Publish 클라이언트라 하고, 클라이언트(10)를 Subscribe 클라이언트라 할 때, publish 클라이언트와 subscribe 클라이언트가 서로 메시지를 전달하는 중간에서 양자 사이를 중계하는 역할을 한다.
본 발명의 실시예에서는, 통합 SNS 어플리케이션과 게이트웨이(1) 간의 푸시 기반 통신은 오픈 소스 프로젝트로 개발된 MQTT 프로토콜을 사용하는바, 상기 브로커 서버(101)는 Mosquitto를 사용하나 이에 한정되지 않는 것은 당연하다.
MQTT는 푸시 기반의 전송방식만을 제공하므로 이를 기반으로 통합 SNS 프로토콜을 설계하여야 하는바, 브로커 서버(101)의 상세한 내용은 통합 SNS 프로토콜 설계와 같이 후술한다.
또한, 보안관리자, 계정관리자(103), 데이터 관리자(104)는 각각 보안기능, 계정관리기능, 데이터 관리 기능을 제공한다. 각 기능은 게이트웨이(1)로서 동작하기 위해서 자체적으로 정의된 세부 기능에 따라서 개발된 구성요소이다.
또한, 상기 캐시 서버(106)는 통합 SNS 어플리케이션에 전송한 내용을 복사하여 저장하고 있다가, 이후에 SNS 어플리케이션에서 동일한 내용을 요청하면 SNS 서버(5)에서 데이터를 받아 오지 않고 저장된 데이터를 곧 바로 보낸다.
상기 캐시 서버(106)는 오픈소스 프로젝트로 개발된 Squid 캐시 서버(106)를 이용할 수 있다. Squid 서버는 캐시 및 프록시를 위한 서버이다. 앞서 설명한 바와 같이 기존의 SNS 프로토콜이 HTTP 기반으로 만들어져 있으므로 웹 캐싱기능을 기본으로 활용할 수 있으며 Squid 서버의 기능을 활용할 수 있다. 또한, Squid 캐시 서버(106)에 캐싱 여부를 판단하는 부분을 개선하여 SNS 프로토콜에서 캐싱이 가능하도록 개선할 수 있다.
또한, 상기 동기화 서버(105)는 서로 다른 위치에 있는 장치 또는 프로그램 간에 동일한 데이터를 유지하기 위한 방법으로, 본 발명의 실시예에서는 클라이언트(10)와 SNS 서버(5)간에서 서로 변경된 부분만을 주고받는 받는다.
상기 동기화 서버(105)는 오픈소스 프로젝트로 개발되는 Funambol 동기화 엔진을 활용할 수 있다. Funambol 동기화 엔진은 동기화 표준 프로토콜인 SyncML 프로토콜에 기반하여 개발되었다. 이 엔진은 동기화를 위한 객체에 따라서 별도로 어댑터를 개발할 수 있은 방법을 제공하고 있다. 게이트웨이(1)는 SNS 객체에 대하여 객체 트리를 구성하고 이 트리를 기반으로 변화된 정보를 계산할 수 있도록 개선하였다.
도 3은 본 발명의 일 실시예에 따라 각 SNS 서버(5)의 콘텐츠별로 객체 트리를 구성한 것이다.
예를 들어, 페이스북 서버의 경우, 콘텐츠 종류(예를 들어 이미지, 텍스트, flash, 비디오)의 확장자를 하나의 객체로 하여 트리를 구성할 수 있다.
또한, 웹 서비스 어댑터(107)는 게이트웨이(1)가 각 SNS서비스별로 사용하는 독특한 프로토콜을 사용하여 각 SNS 서버(5)에 접속할 수 있도록 한다 웹 서비스 어댑터(107)는 SNS별로 개발되어야 하며 각 SNS에서 제공하는 개발 플랫폼을 사용하여 개발한다.
예를 들어, Facebook의 웹 서비스 어댑터(107)는 Facebook에서 제공하는 Facebook SDK로 페이스북의 어댑터를 개발하여 추가시키면 된다.
도 4는 본 발명의 일 실시예에 따라 게이트웨이(1)의 각 구성요소 간의 동작 과정을 나타내는 서버 순차 다이어그램이고, 도 5는 본 발명의 일 실시예에 따라 통합 어플리케이션에서 데이터를 갱신하는 동안 게이트웨이(1) 서버의 각각의 구성요소 간의 동작 과정을 나타내는 순서도이다.
도 4과 도 5를 참조하여, 클라이언트(10)가 하나의 페이지를 통합 SNS 어플리케이션에서 갱신하는 동안 게이트웨이(1) 서버의 각 구성요소간의 동작 과정을 설명하겠다.
먼저, 클라이언트(10)가 통합 SNS 어플리케이션을 이용하여 MQTT 프로토콜로 브로커 서버(101)에 페이지를 요청한다.(S501)
브로커 서버(101)는 클라이언트(10)가 요청한 페이지와 상기 페이지에 해당하는 SNS 서버(5)를 매칭하고, 계정관리자(103)에게 클라이언트(10)의 인증을 요구하며, 클라이언트(10)의 페이지를 요청을 전송한다.(S502)
이후, 계정관리자(103)는 클라이언트(10) 인증을 위해 클라이언트(10)의 ID를 확인하고(S503), 클라이언트(10)의 ID가 인증되지 않은 경우 다시 브로커 서버(101)를 통해 클라이언트(10)에게 인증 실패에 따른 거부 메세지를 보낸다.(S504)
클라이언트(10) ID가 인증된 경우, 페이지에 대한 요청을 데이터 관리자(104)에게 보낸다. 데이터 관리자(104)는 캐시 서버(106)에 클라이언트(10) 요청 페이지에 대한 콘텐츠가 있는지 확인한다.(S505)
캐시 서버(106)에 해당 콘텐츠가 있는 경우, 캐시 서버(106)는 상기 콘텐츠를 데이터 관리자(104)로 전송하고(S506), 데이터 메니저는 브로커 서버(101)로 상기 콘텐츠를 전송하며(S510), 브로커 서버(101)는 클라이언트(10)에게 페이지 요청에 따른 응답을 하게 된다.(S511)
캐시 서버(106)에 해당 콘텐츠가 없는 경우, 캐시 서버(106)는 웹 서비스 어댑터(107)로 SNS 서버에 상기 페이지를 요청한다.(S507) 웹 서비스 어댑터(107)는 페이지 요청에 해당하는 SNS 서버(5)의 프로토콜로 상기 페이지를 요청하고 요청에 대한 응답을 받는다.(S508)
웹 서비스 어댑터(107)는 응답에 해당하는 콘텐츠를 캐시 서버(106)에 저장하고, 데이터 관리자(104)로 상기 콘텐츠를 전송한다.(S509)
데이터 관리자(104)는 상기 콘텐츠를 브로커 서버(101)로 전송하고(S510), 브로커 서버(101)는 클라이언트(10)에게 페이지 요청에 따른 콘텐츠 응답을 전송하게 된다.(S511)
클라이언트(10)에서 자주 요청되는 콘텐츠를 캐싱한다면, 실제 SNS 서버(5)에 도달하지 않고, 게이트웨이(1) 서버에서 클라이언트(10)에게 콘텐츠를 제공하게 되므로, 트래픽과 응답 시간을 줄일 수 있다.
도 6은 본 발명의 일 실시예에 따라 SyncML 이용한 동기화 방법의 순차다이어그램을 나타낸다.
도 6를 참조하여, Funambol 동기화 엔진의 동기화 표준 프로토콜인 SyncML 프로토콜을 이용한 동기화 방법을 설명하겠다.
먼저, SNS 서버(5)는 클라이언트(10)에게 갱신된 콘텐츠가 있는 경우 푸시 메세지(Push Message) 및 갱신된 콘텐츠의 데이터를 상기 SNS 서버(5)의 프로토콜로 전송한다.
이후, 웹 서버스 어댑터는 상기 SNS 서버(5)의 어댑터로 갱신된 데이터를 전송 받는다.
웹 서비스 어댑터(107)가 갱신된 데이터를 전송 받는 동안, 동기화 엔진은 전송받은 데이터 중 변경된 데이터가 있는지 확인하고, 변경된 데이터만을 동기화 서버(105)로 전송한다.
이때, 동기화 엔진은 SNS 서버(5)가 데이터를 전송하는 동안 위 과정을 반복하게 된다.
이 후, 동기화 서버(105)는 전송받은 데이터로 갱신하여 동기화를 마친다.
위 방법으로 데이터를 갱신하면, 동기화 서버(105)는 변화된 부분만을 전송하여 SNS 서버(5)의 데이터와 일치시킴으로 응답속도와 트래픽 성능을 향상시킬 수 있다.
이하에서는 통합 SNS 프로토콜 설계에 대한 내용을 기술한다.
본 발명의 일 실시예는, MQTT를 기반으로 통합 SNS 프로토콜을 설계한다. 다만, 이에 한정되지 아니함은 당연하다.
먼저, MQTT에 대하여 간략하게 설명하면, MQTT는 기본적으로 1개의 브로커 서버(101)와 2개의 Publish 클라이언트와, Subscribe 클라이언트로 구성된다.
이하 설명에서는 SNS 서버(5)를 publsh 클라이언트(801)로, 클라이언트(10)를 Subscribe 클라이언(802)트로 표현하겠다. 다만, SNS 서버(5)가 subscribe 클라이언트로, 클라이언트(10)가 publsh 클라이언트가 될 수도 있다.
브로커 서버(101)는 2개의 Publish, Subscribe 클라이언트 사이에서 주어지는 Topic에 대한 메시지 전달의 중계자 역할을 한다. Publish 클라이언트가 Topic을 발행하고 메시지를 브로커 서버(101)로 전달하면, Subscribe 클라이언트는 관심 있는 Topic을 subscribe하게 된다.
위와 같은 동작을 하기 위해 MQTT 기반의 프로토콜 설계는 다음과 같이 3가지 사항을 규정해야 한다. 첫째는 전달할 메시지의 Topic Tree, 둘째는 QoS 수준, 셋째는 메시지의 길이이다.
도 7은 본 발명의 일 실시예에 따라 Topic tree의 구성을 나타낸다.
먼저, 도 7를 참조하여, Topic tree 구성의 설정 방법을 설명하겠다.
MQTT는 Publish/Subscribe 클라이언트와 Broker 서버 간의 푸시 서비스를 위하여 Topic을 사용한다. Topic tree는 각각의 Topic에 대하여 더욱 세분화하여 Topic을 관리하기 위해 사용한다.
이때 각 유저마다 사용하는 SNS가 다르고, SNS의 기능이 다르므로, 유저 ID마다 SNS와 기능별로 Topic 구분지어 관리해야 한다.
각각의 SNS와 기능에 대하여 푸시 알림 메시지를 판단하기 위해 Topic tree에 대한 정의를 도 7의 예시로 설정하면, 브로커 서버(101)는 Publish 클라이언트의 Topic을 보고, 구독을 요청한 Subscribe 클라이언트들에게만 메시지들을 보내게 된다.
도 8은 Qos(Quality of Service) 레벨에 따른 패킷 교환 방법을 나타낸다
Qos란 인터넷이나 네트워크 상에서 전송률 및 에러율과 관련된 서비스 품질을 가리키는 말이다.
MQTT 는 메시징에 대한 신뢰성 보장을 위하여 3단계의 QoS를 지원한다.
도 8를 참조하면, qos 0(700)은 메시지를 한 번만 전달하고 전달 여부는 확인하지 않는다. 따라서 큰 페이로드를 가지는 메시지일 경우, 패킷 손실이 발생하면 메시지가 전달되지 않고 유실될 가능성이 높다. qos 1(701)은 메시지를 최소 1번 이상 전달하고 전달 여부를 확인한다. 하지만 PUBACK 패킷이 유실된다면 메시지가 불필요하게 중복 전달될 가능성이 있다. qos 2(702) 는 4-way handshake을 통해 정확하게 한 번만 전달한다. qos 2(702)를 사용한다면 메시지가 유실될 가능성은 없지만 4-way handshake 과정에 의하여 종단 간 지연이 늘어나게 된다. QoS 레벨이 높을수록, 패킷을 교환하는 횟수가 늘어나기 때문에 상대적으로 종단 간 지연은 늘어나게 된다.
재전송시간은 전달해야 할 메시지의 내용은 전송 프로토콜로서 전달하고자 하는 Publish 클라이언트에서 메시지가 정확하게 Subscribe 클라이언트까지 전달하기 위해서는 높은 QoS 레벨을 사용하는 것이 좋은 방법이다. 하지만 이 경우 그만큼 종단 간 지연은 늘어나게 된다. 만약 페이로드 크기에 대한 패킷 손실과 종단 간 지연에 대한 결과를 분석하여 페이로드 크기에 따른 적절한 QoS 레벨을 도출할 수 있다면, MQTT를 사용함에 있어서 더욱 효과적인 푸시 알림 서비스 네트워크 환경을 구성할 수 있을 것이다.
그러므로 이하에서는 먼저,QoS 수준과 메시지 길이를 결정하기 위한 실험 환경과 측정방법을 설명하고 두 번째는 실험결과와 이를 바탕으로 도출된 결정사항을 제시하여 통합 SNS 프로토콜을 설계하겠다.
도 9는 본 발명의 일 실시예에 따라 MQTT 의 메시지 전달과정을 나타낸다.
도 10은 본 발명의 일 실시예에 따라 통합 SNS 프로토콜의 설계를 위한 실제 네트워크 실험 구성을 나타낸다.
도 9와 도 10을 참조하여, 실제 네트워크 환경에서 단말과 게이트웨이(1) 서버 사이에서 MQTT의 QoS 레벨과 페이로드 크기에 따른 종단 간 지연 및 패킷 손실의 성능 분석을 위한 네트워크 환경 및 패킷 측정 방법에 대하여 설명한다.
실험을 위한 서버의 OS는 Linux 환경의 CentOS 6.3 Final이며, 브로커 서버(101) 소프트웨어는 오픈 소스 프로젝트인 Mosquitto를 활용할 수 있다.
MQTT는 Publish 클라이언트와 Subscribe 클라이언트사이의 브로커 서버(101)를 통하여 메시지를 전달한다. 도 9은 각각의 클라이언트들이 브로커 서버(101)를 통하여 해당하는 Topic에 메시지를 전달하는 과정을 보여준다.
Publish 클라이언트는 발행하고자 하는 Topic을 브로커 서버(101) 측에게 알린다. 브로커 서버(101)는 발행하는 Publish 클라이언트의 Topic과 subscribe하는 Subscribe 클라이언트의 Topic이 동일한 Topic일 경우, 해당 Topic을 기준으로 클라이언트 간 메시지 전달의 중계 역할을 하게 된다. Subscribe 클라이언트는 브로커 서버(101)에게 subscribe 요청을 한 Topic에 한하여 메시지를 전달받는다.
예를 들어, Publish 클라이언트가 A라는 Topic을 브로커 서버(101)에게 전달하게 되고, 다수의 Subscribe 클라이언트가 A라는 Topic을 subscribe을 요청하게 된다면, A Topic으로 subscribe을 요청한 Subscribe 클라이언트에 한하여, Publish 클라이언트의 메시지를 전달 받게 된다.
본 발명의 실시예에서는 실제 네트워크와 유사한 환경에서의 실험을 위하여 클라이언트(10)와 게이트웨이(1) 간의 통신환경을 도 10과 같이 구현할 수 있다.
도 10을 참조하면, 휴대용 단말에서 3G망을 거쳐 브로커 서버(101)로 통신함으로써 실제 무선 네트워크 환경에서의 실험과 동일하다고 볼 수 있다.
실험은 Android 2.3 환경에서 IA92 라이브러리를 이용한 JAVA언어 기반의 클라이언트(10)에서 실험을 진행하였다. 실험 대상 기기의 MTU(Maximum Transmission Unit)는 1,500으로 설정되어 있다.
본 발명의 실시예에서는 패킷을 수집하기 위하여 Shark 애플리케이션을 이용하였다. 모바일 환경에서는 패킷을 캡처하기 위해서 제한된 환경이므로 Shark 애플리케이션을 통하여 패킷을 캡처하고 저장되는 Pcap 파일을 Wireshark로 패킷 분석을 한다. 5분의 측정 시간 동안 서버와 클라이언트(10) 사이의 패킷을 수집하여 종단 간 지연과 패킷 손실을 분석한다. 종단 간 지연 측정은 Publish 클라이언트에서 게이트웨이(1) 서버를 지나서 Subscribe 클라이언트까지의 타임스탬프를 이용하여 측정한다. 패킷 손실 측정 방법은 5분 동안 측정한 패킷들의 재송신 요청 패킷들을 카운트하여 측정한다.
도 11은 도 10의 실험의 평균 종단 간 지연의 분석결과를 나타내는 도면이고, 도 12는 도 10의 실험의 패킷 손실의 분석 결과를 나타내는 도면이다.
도 11과 도 12를 참조하여, 본 발명의 일 실시예에 따른 위의 실험을 토대로 패킷에 대한 종단 간 지연과 패킷 손실에 대해 분석을 하고, QoS 레벨과 페이로드 에 따른 종단 간 지연과 패킷 손실에 대하여 결과를 제시한다. 또한 이 결과를 바탕으로 통합 SNS 프로토콜로 사용하기 위한 설정값을 제시한다.
아래의 도 11은 게이트웨이(1) 서버와 단말 간의 QoS 레벨과 페이로드에 대한 종단 간 지연 결과를 비교하는 그래프이다. 전반적으로 QoS 레벨이 증가함에 따라 평균 종단 간 지연이 증가한 것을 볼 수 있다. 그 이유는 QoS에 따른 패킷의 송/수신 개수의 차이 때문이다. 평균적으로 큰 종단 간 지연 현상을 보여주는데, 이는 무선 네트워크 3G망의 전송속도가 지연 현상의 원인이 된다.
페이로드의 크기가 4,000에서 증가폭이 상당히 급격해 진다. qos 0(700)의 경우는 4,000에서 0.65에서 0.61로 오히려 감소하였고 qos 1(701)은 0.57로 그대로 유지하고 있으며 QoS는 0.47로 페이로드 길이가 1,000일 경우와 같은 값이다. 그러나 페이로드 길이 4,000을 기점으로 모든 QoS 수준에서 전달지연이 최소 0.15이상씩 증가하였다.
한 가지 더 주목할 만한 점은 QoS 별로 전달지연이 크지 않다는 점이다. 결론적으로 전달지연에 관하여는 QoS 수준은 고려하지 않아도 되고 페이로드 크기는 4,000 이하로 하는 것이 좋다는 결론이다.
도 12는 게이트웨이(1) 서버와 단말 간의 패킷 손실률을 분석한 결과이다.
실험 결과 전체적으로 qos 0(700), qos 1(701)과 비교하면 qos 2(702)의 패킷 손실이 낮은 것을 확인할 수 있다. 전체적으로 패킷 손실률은 안정적이지만, qos 0(700)이나 qos 1(701)에 비교하여 상대적으로 qos 2(702)의 패킷 손실이 낮은 이유는 4-way handshake를 이용하여 메시지를 전달하므로 손실률이 줄어든 것이다.
게이트웨이(1)와 통합 SNS 애플리케이션 사이의 통신은 매우 안정적으로 전달되어야 한다. 특히 동기화 기능을 활용하기 위해서는 안정된 프로토콜이 반드시 필요하다. 따라서 패킷손실이 적은 qos 2(702)가 적합하다.
본 발명의 실시예에서는 폭발적으로 증가하는 SNS 트래픽에 대응하기 위하여, 게이트웨이(1)를 활용한 통신성능 개선 방안을 제시하였다. 제시한 방안을 실현하기 위한 게이트웨이(1)의 상위 설계 결과를 게이트웨이(1)의 상위 설계 결과를 확인하는 것이 가능하였고, 게이트웨이(1) 서버와 단말의 통신을 위하여 MQTT기반 SNS 통합 프로토콜 설계 결과도 확인할 수 있었다. 특히, 실시예의 게이트웨이(1)는 캐싱 및 동기화 역할을 수행하면서, 기존과 대비하여 통신 성능을 향상시킬 수 있다. 그리고, SNS 통합 프로토콜은 MQTT를 기반에서 동작가능하며, MQTT의 성능에 대해서도 신뢰성 높은 결과를 얻는 것이 가능하다.

Claims (3)

  1. 네트워크 연결된 적어도 하나 이상의 클라이언트와 통합 SNS 프로토콜로 통신하고, 복수의 SNS 서버간의 메시지 전달을 중계하는 브로커 서버(101)와,
    상기 브로커 서버(101)로부터 클라이언트의 메시지와 ID 정보를 받고, 클라이언트의 계정을 관리하는 계정관리자(103)와,
    상기 계정관리자(103)의 ID 승인 및 메시지 요청을 받고, 캐시 서버(106)와 동기화 서버(105)의 데이터를 관리하는 데이터 관리자(104)와,
    상기 데이터 관리자(104)의 명령에 따라 동기화 기능을 담당하는 동기화 서버(105)와,
    상기 데이터 관리자(104)의 명령에 따라 캐싱 기능을 담당하는 캐시 서버(106)와,
    상기 동기화 서버(105)와 상기 캐시 서버(106)의 명령을 수신하고, 각각의 SNS 서버와 개별적인 프로토콜에 따라 통신을 수행하는 웹 서비스 어댑터(107)를 포함하는 통합 SNS 게이트웨이.
  2. 제1항에 있어서,
    상기 동기화 서버(105)는, 상기 웹 서비스 어댑터(107)를 통해 연결되는 각각의 SNS 서버별로 동기화 항목을 개별적으로 설정하여 두는 것을 특징으로 하는 통합 SNS 게이트웨이.
  3. 제1항에 있어서,
    상기 캐시 서버(106)는, 상기 클라이언트로부터 페이지에 대한 요청이 있는 경우에, 상기 브로커 서버(101)에 의해 중계된 SNS 서버로 해당 페이지에 대한 콘텐츠를 선택적으로 요청하는 것을 특징으로 하는 통합 SNS 게이트웨이.
PCT/KR2014/002410 2013-03-21 2014-03-21 통합 sns 게이트웨이 WO2014148865A1 (ko)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
KR1020130030335A KR101375133B1 (ko) 2013-03-21 2013-03-21 통합 sns 게이트웨이
KR10-2013-0030335 2013-03-21

Publications (1)

Publication Number Publication Date
WO2014148865A1 true WO2014148865A1 (ko) 2014-09-25

Family

ID=50648895

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2014/002410 WO2014148865A1 (ko) 2013-03-21 2014-03-21 통합 sns 게이트웨이

Country Status (2)

Country Link
KR (1) KR101375133B1 (ko)
WO (1) WO2014148865A1 (ko)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3386171A1 (en) * 2017-04-05 2018-10-10 Rockwell Automation Technologies, Inc. Common gateway platform

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015152698A1 (ko) * 2014-04-04 2015-10-08 주식회사 퓨전소프트 Sns 트래픽 개선을 위한 통합 sns 게이트웨이
KR101579525B1 (ko) * 2014-04-04 2016-01-04 주식회사 퓨전소프트 웹 서비스 어댑터 및 이를 포함하는 통합 sns 게이트웨이
KR102476831B1 (ko) 2016-02-26 2022-12-13 엘에스일렉트릭(주) 전력 시스템에서의 통신 장치 및 이의 통신 방법
US10003662B1 (en) * 2017-03-01 2018-06-19 Two Degrees, Inc. Adaptable broker for location based second degree social networking
KR101905012B1 (ko) * 2017-07-26 2018-10-05 주식회사 인피니헨스 복수 소셜 네트워크 서비스의 통합 관리를 위한 sns 매니지드 시스템

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2007156779A (ja) * 2005-12-05 2007-06-21 Hitachi Ltd センサネットシステム、基地局及びセンシングデータの中継方法
JP2010154086A (ja) * 2008-12-24 2010-07-08 Sharp Corp 通信制御装置、通信制御装置の通信制御方法、制御プログラム、および、記録媒体
KR20120075630A (ko) * 2010-12-20 2012-07-09 주식회사 케이티 홈 기기 정보를 이용한 홈 소셜 네트워크 서비스 시스템 및 그 방법
KR20130023970A (ko) * 2011-08-30 2013-03-08 티스트림 주식회사 트래픽 제어 게이트웨이 및 이를 이용한 트래픽 제어 방법

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101236500B1 (ko) 2011-11-29 2013-03-15 주식회사 대명엔터프라이즈 소형 임베디드 장치를 위한 ｓｎｓ 중계 서비스 장치 및 그 방법

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2007156779A (ja) * 2005-12-05 2007-06-21 Hitachi Ltd センサネットシステム、基地局及びセンシングデータの中継方法
JP2010154086A (ja) * 2008-12-24 2010-07-08 Sharp Corp 通信制御装置、通信制御装置の通信制御方法、制御プログラム、および、記録媒体
KR20120075630A (ko) * 2010-12-20 2012-07-09 주식회사 케이티 홈 기기 정보를 이용한 홈 소셜 네트워크 서비스 시스템 및 그 방법
KR20130023970A (ko) * 2011-08-30 2013-03-08 티스트림 주식회사 트래픽 제어 게이트웨이 및 이를 이용한 트래픽 제어 방법

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3386171A1 (en) * 2017-04-05 2018-10-10 Rockwell Automation Technologies, Inc. Common gateway platform
CN108696574A (zh) * 2017-04-05 2018-10-23 罗克韦尔自动化技术公司 公共网关平台
US10467072B2 (en) 2017-04-05 2019-11-05 Rockwell Automation Technologies, Inc. Common gateway platform
US10896079B2 (en) 2017-04-05 2021-01-19 Rockwell Automation Technologies, Inc. Common gateway platform
CN108696574B (zh) * 2017-04-05 2021-05-25 罗克韦尔自动化技术公司 公共网关平台
US11226855B2 (en) 2017-04-05 2022-01-18 Rockwell Automation Technologies, Inc. Common gateway platform
US11822981B2 (en) 2017-04-05 2023-11-21 Rockwell Automation Technologies, Inc. Common gateway platform

Also Published As

Publication number Publication date
KR101375133B1 (ko) 2014-03-17

Similar Documents

Publication Publication Date Title
WO2014148865A1 (ko) 통합 sns 게이트웨이
US10455046B2 (en) Choreographed caching
KR101263783B1 (ko) 릴레이 서버를 이용한 데이터 전송 시스템 및 방법
US20140269777A1 (en) Resynchronization of passive monitoring of a flow based on hole detection
CN102932461B (zh) 网络加速传输方法及装置
WO2012157940A2 (ko) 피드백메시지를 이용한 푸시 서비스 제공 시스템 및 방법
WO2016013718A1 (ko) 와이파이 망을 이용한 웹기반 광고 제공 시스템 및 방법
US11533275B2 (en) Method and apparatus for allocating server in wireless communication system
WO2015056833A1 (en) Web-based real time data pushing method and system thereof
JP5913258B2 (ja) 中継装置及びデータ転送方法
WO2015002443A1 (en) Mobile device and method for controlling transmission to web server in mobile device
US20140304419A1 (en) System and terminal for p2p connection in mobile environment and method for p2p connection using the same
US20160277289A1 (en) Federation of controllers management using packet context
CN103916489B (zh) 一种单域名多ip的域名解析方法及系统
JP6393475B2 (ja) 通信アダプタ装置、通信システム、トンネル通信方法、及びプログラム
JP4855441B2 (ja) 通信装置、遠隔通信分析システムおよび通信方法
CN110771117A (zh) 一种采用面向id的网络的会话层通信
US20200106515A1 (en) Communication Device, Relay Device, Information Processing System, Communication System and Communication Method
KR102011806B1 (ko) Udt 기반 트래픽 가속 방법
CN112838933A (zh) 一种网络流量分析中的信息同步方法、设备及存储介质
US10111081B2 (en) Local communication wireless network system and method thereof
JP2019103118A (ja) 通信中継装置、通信中継プログラム、および通信中継方法
US20090052446A1 (en) Communications Interface
WO2018206095A1 (en) Apparatus and method for communicating sim data
CN109495570B (zh) 采样报文的转发方法、装置及数据中心

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: 14768013

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 20.01.2016)

122 Ep: pct application non-entry in european phase

Ref document number: 14768013

Country of ref document: EP

Kind code of ref document: A1