CN108733495B

CN108733495B - Method and apparatus for enabling cross-platform communication

Info

Publication number: CN108733495B
Application number: CN201710241440.XA
Authority: CN
Inventors: 张立杰; 杨建东
Original assignee: Oriental Pearl Group Co ltd
Current assignee: Oriental Pearl Group Co ltd
Priority date: 2017-04-13
Filing date: 2017-04-13
Publication date: 2022-01-28
Anticipated expiration: 2037-04-13
Also published as: CN108733495A

Abstract

The application aims to provide a method and equipment for realizing cross-platform communication, wherein a < share > tag is defined, and the tag comprises more than two interfaces; analyzing each interface in the < share > tag to obtain the support information of each interface; establishing a cross-platform communication network protocol stack between a client and a server; and performing cross-platform communication functional service between the client and the server according to the cross-platform communication network protocol stack, the interface and the support information thereof. The method can realize the cross-platform function of the application, and the application can support the cross-platform communication function on various platforms, not only limited to the same platform.

Description

Method and apparatus for enabling cross-platform communication

Technical Field

The present application relates to the field of computers, and more particularly, to a technique for implementing cross-platform communication.

Background

Html is a technical standard issued by W3C, and is also a programming language, and web applications are implemented with CSS (Cascading Style Sheet) and JS (JavaScript, a scripting language for implementing web applications) and the like based on various tags and related interfaces and attributes. The current latest version is html 5. Html is a weak language, and can be operated only by directly analyzing by an Html analysis engine without compiling. Typical html parsing engines are, for example, Webkit, Blink, Trident, Gecko, etc. Most modern browsers already have some HTML5 support. However, since html5 is part of the technical front end, many techniques are still under development. The cross-platform information sharing aspect of the html5 specification, for example, is not specified in the published specification.

At present, the communication functions of the platforms are limited to the same platform, for example, the Android (Android) self-contained video sharing wireless protocol (miracast) communication application is limited to the Android platform; the application of the Linux system is limited to the application with the same architecture and the same platform; iOS applications are limited to iOS usage only. Of course, the Android and iOS devices can communicate with each other, but such communication is only limited to cross-platform communication of network protocols, not application-level cross-platform communication.

Disclosure of Invention

The application aims to provide a method and equipment for realizing cross-platform communication, which can solve the problem that the application cannot support the cross-platform communication function on various platforms in the prior art.

According to one aspect of the application, a method for enabling cross-platform communication is provided, comprising:

defining a < share > tag, the tag comprising two or more interfaces;

analyzing each interface in the < share > tag to obtain the support information of each interface;

establishing a cross-platform communication network protocol stack between a client and a server;

and performing cross-platform communication functional service between the client and the server according to the cross-platform communication network protocol stack, the interface and the support information thereof.

According to another aspect of the present application, there is also provided an apparatus for implementing cross-platform communication, including:

defining means for defining a < share > tag, said tag comprising two or more interfaces;

the analysis device is used for analyzing each interface in the < share > tag to obtain the support information of each interface;

the device comprises an establishing device, a processing device and a processing device, wherein the establishing device is used for establishing a cross-platform communication network protocol stack between a client and a server;

and the communication device is used for performing cross-platform communication functional service between the client and the server according to the cross-platform communication network protocol stack, the interface and the support information thereof.

Compared with the prior art, the method has the advantages that the < share > tag is defined, and the tag comprises more than two interfaces; analyzing each interface in the < share > tag to obtain the support information of each interface; establishing a cross-platform communication network protocol stack between a client and a server; and performing cross-platform communication functional service between the client and the server according to the cross-platform communication network protocol stack, the interface and the support information thereof. The method can realize the cross-platform function of the application, and the application can support the cross-platform communication function on various platforms, not only limited to the same platform.

Drawings

Other features, objects and advantages of the present application will become more apparent upon reading of the following detailed description of non-limiting embodiments thereof, made with reference to the accompanying drawings in which:

FIG. 1 illustrates a device architecture diagram for implementing cross-platform communication in accordance with an aspect of the subject application;

FIG. 2 shows a BesTV TVOS architecture diagram to which the present application relates;

FIG. 3 illustrates a schematic diagram of a device module for implementing cross-platform communication in a preferred embodiment in accordance with an aspect of the subject application;

FIG. 4 shows a schematic diagram of a parsing device in accordance with a preferred embodiment of an aspect of the present application;

FIG. 5 illustrates a device architecture diagram for implementing cross-platform communication in accordance with another aspect of the subject application;

fig. 6 shows a schematic flow chart of step S12 according to a preferred embodiment of another aspect of the present application.

The same or similar reference numbers in the drawings identify the same or similar elements.

Detailed Description

The present application is described in further detail below with reference to the attached figures.

FIG. 1 illustrates a device architecture diagram for implementing cross-platform communication in accordance with an aspect of the subject application; the device 1 comprises defining means 11, parsing means 12, establishing means 13 and communication means 14. Wherein the defining means 11 defines a < share > tag, which comprises more than two interfaces; the analyzing device 12 analyzes each interface in the < share > tag to obtain the support information of each interface; the establishing device 13 establishes a cross-platform communication network protocol stack between the client and the server; the communication device 14 performs a cross-platform communication function between the client and the server according to the cross-platform communication network protocol stack, the interface and the support information thereof.

The device for realizing cross-platform communication is based on cross-platform communication realized by BesTV TVOS, is used for TV services, and comprises ott (Internet TV service Over The Top), iptv (Interactive Internet television (Internet television) Internet, dvb (Digital television (Digital Video Broadcasting)), html5(Hyper Text Markup Language 5), network application realized by HTML5, and The like. The BesTV TVOS is an operating system implemented based on a webpage, and all applications are essentially implemented based on the webpage. The BesTV TVOS does not implement the window system itself, but rather it is implemented through a web control. The browser functionality in the BesTV TVOS no longer appears as an application, but as a system function. All applications conform to the html5 standard to achieve cross-platform objectives, i.e., to run web applications on other systems that conform to html5 standard functionality. In the embodiments described below in this application, all are performed on the BesTV TVOS architecture. Wherein, the architecture diagram of BesTV TVOS is shown in FIG. 2. In fig. 2, the Webapp part mainly includes Desktop/launcher UI (user interface of Desktop or Desktop application), system app (application), tv app, etc., which are all implemented in a web page form, local page or web page, so as to achieve the purpose of cross-platform; the Web frame module realizes the functions of basic system function, television service, value-added service and the like necessary for the set-top box based on html5 and js (JavaScript, Web scripting language), and the part is divided into three layers, and the total number of the modules is 6: webos api, sdk api (programming interface for software development kit) like andorid; TV frame specifically realizes related functions of TV service and the like; system frame: various system management functions; the server/service/manager realizes various functions of the system, and an ipc (inter-process communication mechanism) mechanism of the system comprises a player function and the like; w3c html/css/js; standard plug-in interfaces, such as npapi (netscape plug in application programming), bho (brown help object), etc. The Web Runtime is realized based on open source blink/v8, is not a simple webkit, v8 function, and needs to comprise four modules: runtime manager function, WebBOM function, Webkit Porting function, Webcore/v8 function. The runtime manager function is management of a module, the WebBOM function realizes a BOM (Browser Object Model) function of w3c, the Webkit Porting realizes a Webkit function including a packaging Webcore and an adaptation platform function, and the Webcore/v8 function follows parsing, layout and rendering engine of html/css/js of GPL specification. Native realizes the function support, mainly includes: audio and video analysis coding and decoding, a graph library, a picture decoding library, a network library, other commonly used necessary function libraries and a JVM (Java virtual machine). The HAL module: an android HAL (Hardware Abstraction Layer) Layer is used to be compatible with android devices while reducing development tasks. The Kernel api: to support different kenel (operating system kernel) that uses linux to perform the kenel level functions.

FIG. 3 illustrates a schematic diagram of a device module for implementing cross-platform communication in a preferred embodiment in accordance with an aspect of the subject application; the equipment module mainly comprises an HTML/CSS/JS API submodule of a Web frame module; a Webcore/v8 sub-module and a Webkit Porting sub-module of the Web Runtime module; a server/service/manager submodule of the Web frame module; and a network library submodule of the Native module. The related HTML/CSS/JS API sub-module is mainly a newly added < share > tag, including the method, attribute and event interface thereof; the Webcore/v8 submodule completes the analysis of the newly added < share > tag, including the analysis of various attributes, methods and events of the < share > tag; the Webkit Porting submodule realizes the calling of a cross-platform communication function service after the resolution engine resolves the newly added < share > tag; the cross-platform communication function service is specifically completed by an upnp service of a server/service/manager submodule, the service is operated in an independent process, and the init is analyzed by an init process in a Bestv TVOS and is started by an init. The network protocol stack required by the upnp service is realized by adding a cross-platform communication upnp network protocol stack to a network sub-module in a native module, and is specifically realized by libipnp. The upnp network protocol stack completes communication with other local area network devices which also support the upnp network protocol stack through http, soap, gena, ssdp and other protocols. The call flow is implemented in the order indicated in fig. 3, and the event implementation process is the reverse. The definition device 11 comprises an HTML/CSS/JS API submodule in FIG. 3, the parsing device 12 comprises Webcore/v8, the establishing device 13 comprises a Native module, and the communication device 14 comprises a Webkit Porting submodule and a server/service/manager submodule.

Those skilled in the art will understand that UPNP (Universal Plug and Play), a network protocol for implementing communication between devices based on TCP/IP protocol, is generally used in a local area network. The whole working process needs to process six aspects of content, namely device addressing, device discovery, device description, device control, device event and device expression. The main protocols used by UPnP are: SSDP (Simple Service Discovery Protocol), GENA (Generic Event Notification Architecture), SOAP (Simple Object Access Protocol), XML (Extensible Markup Language), and the like. An IP protocol is adopted to ensure that UPnP is independent of a physical medium transmitted by a network, an SSDP protocol is adopted to complete equipment management, an SOAP protocol is adopted to ensure that UPnP equipment has interoperability, XML is used to uniformly describe equipment and services, an HTTP protocol is used to perform information interaction of the UPnP equipment, and GENA is used to complete event management of the equipment. The adoption of these existing, widely-used protocols can reduce the workload of developing UPnP devices, enabling UPnP devices to better integrate into existing networks.

In the embodiment of the present application, the function of implementing cross-platform communication is to implement a function supporting a < share > tag based on blink or webkit, and it should be noted that all platforms supporting blink and network applications implemented based on html5 may directly run the method of the present application using the device, and do not need to be compiled. Those skilled in the art should understand that in the embodiment of the present application, the functionality of cross-platform communication is implemented with respect to Bestv TVOS, but other platforms including html5 parsing function may also be implemented with reference to the method in the embodiment, and the platforms include, but are not limited to, platforms supporting blink or Webkit, such as Windows (microsoft Windows operating system)/Chrome (google browser), Ubuntu (operating system based on Linux kernel)/Chrome, Android (google mobile operating system)/Webview (browser frame of Android), Android/Chrome, Tizen (network operating system of three stars), Qt (nokia embedded operating system), and the like. Other existing or future platforms for parsing functions, as applicable to the present application, are also intended to be encompassed within the scope of the present application and are hereby incorporated by reference.

Preferably, said defining means 11 are adapted to: defining related functions, attributes and events of each interface in a < share > tag, wherein the < share > tag is a node in a document object model tree.

Here, the < share > tag belongs to a node in a DOM (Document Object Model), similar to tags < video >, < audio >, < canvas > and the like in html 5. Preferably, the < share > tag related function comprises: an addressing function, a query function, a device list function, a device control function, a device event function, and a device expression function. Preferably, the event comprises: adding a device event, removing the device event, overtime inquiry event, state judgment event, abnormal execution device event, execution request event, message sending event, abnormal message reporting event and response event. Preferably, the attributes include: automatic addressing, automatic querying, timeout setting, automatic verification, preset time interval, and device response.

Here, the communication device 13 is configured to: the corresponding correlation function is executed based on the corresponding event, and the corresponding communication function service is triggered using the corresponding attribute during the execution of the corresponding correlation function.

For example, after the page receives the added device event, the page directly calls the device list function in the event monitoring method to obtain the real-time device list in the local area network. When the auto-query attribute occurs, other universal plug and play (upnp) devices in the local area network are automatically queried.

In a preferred embodiment of the present application, the correlation function, attribute and event of each interface in the < share > tag are specifically defined as follows, 1) the correlation function: the addressing function is share.address (), the query function is share.search (), the device list function is share.deviceList (), the device control function is share.deviceinfo (uuid), the device event function is share.action (uuid, actaG), and the device expression function is share.upnp sendMessaging action (uuid, message). It should be noted that, in the embodiments described below in the present application, the "correlation function" and the "method" are used alternatively, that is, the correlation function is defined as a method for defining an interface. 2) Adding a device event as upnp add device, wherein the corresponding event attribute is share.onepnp add device; removing the device event as upnp removdevice, wherein the corresponding event attribute is share. The timeout query event is upnp search timeout, and the corresponding event attribute is share. The state judgment event is upnp actionok, and the corresponding event attribute is share. The abnormal execution equipment event is upnp actionerr, and the corresponding event attribute is share.onepnp actionerr; the execution request event is upnp, and the corresponding event attribute is share. The sent message event is upnp sendmessageactionok, and the corresponding event attribute is share. The abnormal message report event is upnp sendessageactioner, and the corresponding event attribute is share. The response event is upnp sendmessage action, and the corresponding event attribute is share. It should be noted that, in addition to the events described above, the standard global event in html5 is also supported. 3) The attributes are as follows: the auto-addressing is auto-addressing, auto-search is auto-queried, timeout is set to search timeout, auto-verification is auto-broadcast, preset time interval is auto-broadcast, and device response is deviceabortime.

Address () has no parameter and no return value, and is used for the local webbreak time to control the local upnp device to execute an addressing (address) action in the upnp protocol, which needs to be executed asynchronously, and the function does not need to be executed frequently. search () has no parameter, returns to Refreshing when returning normally, and represents that the ssdp search message has been sent out; when the exception returns, the exception is CanNotRefresh, which indicates that the ssdp search message cannot be sent out. The function is executed asynchronously, and is used for controlling the local upnp device to execute the search action in the upnp protocol by the local webbreak time, and specifically executing the broadcast ssdp search message. While executing, the local upnp device sets a time (time) limit of 5s, i.e. the alive message received within 5s from the remote device responding to the ssdp search message is valid. 5s later, the local upnp device sends a local webunt upnp refreshimeout event. Meanwhile, within 5s, each time a local upnp device queries (search) to an upnp device, an upnp add event is sent to the local webbreak. Share. devicelist () may be called upon arrival of the related event described above to get a real-time list of upnp devices in the local area network. It should be noted that the real-time device list in the local area network can only be obtained by performing the search operation at least once. The function is executed mainly in the two cases (a) and (b) described in the following share. Device list () has no parameter, returns to the device list when normally returning, and returns to null when abnormal, and needs to be executed synchronously. The method is used for acquiring an upnp device list in the local area network, namely, a list consisting of corresponding device identification numbers of upnp devices in the local area network, and the list comprises the local devices. After the search, the deviceList needs to be accessed after an upnp device, upnp refresh timeout event arrives, otherwise, the real-time device list in the local area network cannot be obtained, that is, the devices under the following two conditions cannot be obtained in time: (a) the remote upnp device which has sent an alive broadcast before the local upnp device starts and has not automatically sent the next alive message; (b) remote upnp devices that are exited abnormally and whose expire time has not yet arrived. When the problem in (b) occurs, the local device automatically monitors whether the expire of each device arrives, and if so, the device is automatically deleted. Under normal conditions, each device can automatically send ssdp alive messages at regular time, and prompt each device to update its exception to prevent the corresponding exception from arriving. And other remote devices started after the local device is started can send an alive message, at the moment, the device can prompt the webbreak module to send the page upnp device event, and automatically update the corresponding device list stored in the webbreak, namely, after the page receives the upnp device event, the real-time device list in the local area network can be obtained by directly calling a share. In addition, for the remote upnp device which normally exits after the local device is started, a byebye message is sent each time, at this time, the webruntime corresponding to the local device can receive the upnp address, and automatically update the corresponding device list stored in the webruntime, that is, after the upnp mobile device is received by the page, the real-time device list in the local area network can be obtained by directly calling the share. The parameter of share.deviceinfo (uuid) is uuid, that is, uuid of the device, the device identification number in the device list acquired by share.deviceist (), the device information is returned normally, and the abnormal return is "novevice", which is used to acquire the device information of a certain device, mainly the url address of the xml file thereof, and the function needs to be executed synchronously.

Uuid in parameters of share.action (uuid, actArg) is a device identification number in a device list acquired by share.deviceList (), url address is a website, http:// is required to be started, true is normally returned, the ssop action message is sent out, and a response of an opposite-end upnp device is received; the exception returns to false, indicating that the ssop action message cannot be sent. The function is used for executing the soap action of the upnp protocol, and specifically, a certain upnp device in the local area network executes the action specified by the action arg. Functions that are executed asynchronously; if the execution is successful, it indicates that the soap action message has been sent out, and the message that the opposite-end upnp device responds to the action of the local device upnp has been received, and at this time, the browser corresponding to the local device will receive the upnp loadactionok event. The success only judges the execution state of the soap action, but does not judge the concrete situation that the opposite end equipment executes the actArg under the actArg error. The home page logic should itself guarantee that actArg can execute properly. An execution exception: including internal errors (e.g., actArg too long), an upnp device without uuid designation, a peer device not supporting the action, not being able to connect to the device, and sending an upnp loadactioner event to the page. (this function should be executed after share. search (), otherwise the result cannot be guaranteed.) additionally, other cases: after share.search () is executed to obtain share.deviceList (), and before share.upnp action is executed, the quitted opposite-end upnp device executing share.upnp action will report an error because the opposite-end device cannot be connected, and the upnp module will prompt the webbreak module to send upnp action to the page.

Uuid in the parameters of share.upnp sendmessage action (uuid, message) is the device identification number in the device list acquired by share.devicelist (), and the message is a message sent and cannot be empty, and the character string after the space is ignored. When returning normally, returning to true, indicating that the ssop action message has been sent out and receiving the response of the opposite end upnp device; the exception returns false, indicating that the ssop action message cannot be sent. The function is used for executing the soap action of the upnp protocol, is specifically sent to a certain upnp device in the local area network to access information corresponding to the message, and needs to be executed asynchronously. When the execution is successful: the message that the sendMessage soap action message is sent and the message that the opposite end upnp device responds to the action of the local device upnp action is received, and the webbreak corresponding to the local device is subjected to the event of upnp sendessageaction. The success only judges the execution state of the soap action, and does not guarantee the integrity and the safety of the character string (if the character string is possibly intercepted and changed by a third party). The page should use some logic to ensure integrity and security, such as a string that can be encrypted before transmission to ensure security, and md5 signature to ensure integrity. An execution exception: including internal errors (e.g., message is too long, exceeding 1k), an upnp device without uuid designation, a peer device not supporting the action, not being able to connect to the device, and sending an upnp message action event to the page. This function is preferably executed after share. ) Other cases are as follows: for the opposite-end upnp device which exits after the share.search () is executed to obtain the share.deviceList () and before the share.upnp LoadAction is executed, the execution share.upnp LoadAction reports an error because the opposite-end device cannot be connected, and the upnp module prompts the browser module to send an upnp sendessactioner to the page. In addition, the sender is distinguished: uuid content may be added to the message section to differentiate between senders.

In connection with the preferred embodiment, the device event upnp add: after receiving ssdp alive broadcast messages sent by upnp devices in a local area network, the local devices send messages corresponding to webruntime, and the webruntime updates a device list stored in the local devices and sends upnp add events to pages. The page logic may register the upnp add event with the share. It should be noted that: if the local device start-up occasion is normally within the interval of two ssdp alive messages of the remote upnp device, that is, the remote device does not send out the ssdp alive messages although it exists in the network, the local device is in a so-called blind period, that is, if the search action is not performed, the remote device is not included in the share. To avoid this, each time the webbrunittime is started, the ssdp search action is automatically performed. The event needs to be used in combination with an upnp removdevice and an upnp refreshmeout event.

The remove device event upnp removal is used for two cases: (a) after receiving ssdp byebye broadcast message sent when upnp device in local area network normally exits, local device sends message corresponding to webruntime, webruntime updates device list stored in local device, and sends upnp removdevice event to page. The page logic may register a method for an upnp device event through a share. (b) When the upnp device in the local area network exits abnormally (including program crash, computer crash and network failure), the ssdp byebye message cannot be sent, and at this time, according to the specification of the upnp protocol, the local upnp device can judge that the device exits abnormally according to the previously acquired expair fields of the devices. The time of the expair field set in the current upnp device is 100s, and if no new alive message corresponding to the device exists after 100s, the device is considered to be abnormally exited. At this time, the local upnp device will prompt the webruntime, the corresponding upnp device exits, the webruntime automatically updates the device list stored in the webruntime, and sends an upnp mobile device event to the page. The page logic may register a method for an upnp device event through a share.

Timeout query event upnp searchtimeout: when share & search () is executed to send ssdp search, since it is not known how many upnp devices exist in the lan, it is only possible to receive a ssdp alive message, update a local list, that is, send an upnp add message to the page, and the page logic monitors this event and obtains registered upnp devices through share & deviceist (). The advantage of this event is that already registered messages can be retrieved in time, with the disadvantage that it is not possible to know how many upnp devices the lan eventually has. Thus, upnp provides that a time is set at which the list of devices acquired at the expiration of the time is a list of devices that are destined for all upnp's in the local area network. This time can be estimated according to the actual situation. The current code is specified as 5 s. The method specifically comprises the following steps: when share () is executed to send ssdp search, the local upnp device sets a time limit of 5s, i.e. the alive message sent by the remote device within 5s and responding to the ssdp search message is valid. 5s later, the local upnp device prompts the local webride time and finally sends an upnp refreshtimeout event to the page. The page logic listens to this event and in this event listening method gets a list of devices in the local area network via share. In addition, when a new device is subsequently provided, since the device sends ssdp alive messages, a real-time device list is obtained through the upnp add device and upnp remote device messages and the monitoring mechanism thereof.

State determination event upnp actionok: after the soap action is successfully executed, that is, the soap action message is sent out, and the message that the opposite-end upnp device responds to the action of the local device upnp action is received, at this time, the webbrunitime corresponding to the local device receives the upnp action event. This success only determines the execution status of the soap action. The specific case of the opposite party performing the action is not concerned. The page logic needs to judge the validity of the action content by itself when executing share.

Abnormal execution device event upnp actionerr: and performing the soap action abnormally, wherein the soap action comprises an internal error (such as an action character string is too long), an upnp device without the uuid specification and an opposite terminal device do not support the action, and when the opposite terminal device cannot be connected, the local upnp device prompts a local webbrunittime to send a page upnp action event.

Execution request event upnp: the upnp device responds to the soap action request sent by the remote device, executes the specific action and sends the action to the corresponding upnp action event of the page.

Send message event upnp sendmessage actionok: after the soap SendMessage action is successfully executed, that is, the soap SendMessage action message is sent out, and the message that the opposite end upnp device responds to the action of the local device upnp action is received, at this time, the page corresponding to the local device is subjected to the event of upnp SendMessage action. This success only judges the execution status of the soap SendMessage action. Security and integrity traffic of the message itself is not a concern. When executing share, upnp sendmessage action, the page logic needs to determine the security and integrity of the message by itself.

Exception message reporting event upnp sendmessage actioner: the soap SendMessage action is executed abnormally, wherein the action comprises an internal error (such as a long message), an upnp device without uuid designation and an opposite device which do not support the action, and when the opposite device cannot be connected, the local upnp device prompts the local webbruunt to send a page upnp SendMessage action event.

Response event upnp message action: the upnp device responds to the soap SendMessage action request sent by the remote device, sends a new message to the browser, and sends a corresponding upnp SendMessage action event.

Preferably, the communication means 13 are configured to: according to the timeout setting, triggering corresponding communication function service comprises inquiring the timeout time of other universal plug and play devices in the local area network; according to the automatic verification, triggering the corresponding communication function service comprises automatically sending a simple service discovery protocol message; and according to the preset time interval, triggering the corresponding communication function service, including automatically sending a simple service discovery protocol message, and determining the time interval of the simple service discovery protocol message.

Here, the attribute searchtimeout is used to set the timeout time of other upnp devices in the search local area network, and the attribute autobroadcast is used to automatically send out ssdp messages to prove that the device exists; the attribute autobroadcastime is used to automatically issue the time interval for ssdp presence messages.

More preferably, the communication device 13 is further configured to: and according to the automatic addressing, triggering the corresponding communication function service to comprise the automatic addressing of the local universal plug and play equipment. Here, the local upnp device automatically addresses if the autoaddress attribute is present. More preferably, the communication device 13 is further configured to: and according to the automatic query, triggering the corresponding communication function service, including automatically querying other universal plug and play devices in the local area network. Here, if the autosearch attribute occurs, the other upnp devices in the autosearch local area network are automatically searched. More preferably, the communication device 13 is further configured to: and according to the equipment response, wherein the equipment response is that the equipment response is not received in the time interval, and the triggering of the corresponding communication function service comprises setting automatic suspension of sending messages. Here, the attribute deviceabortime is used for not receiving the device presence message within the time interval of the ssdp presence message issued, and autobroadcast is set to prove the device exception exit.

Preferably, fig. 4 shows a schematic structural diagram of a parsing apparatus according to a preferred embodiment of an aspect of the present application. The analysis device 12 includes: a first supporting unit 121, a second supporting unit 122, and a third supporting unit 123, where the first supporting unit 121 is configured to define an interface of the < share > tag in a browser engine, and create supporting information corresponding to the interface; a second supporting unit 122, configured to parse the lexical and grammatical rules of the < share > tag to obtain supporting information of the lexical and grammatical rules; a third supporting unit 123, configured to create supporting information for a < share > tag node in the constructed document object model tree.

Here, the resolution of the newly added < share > tag is completed, including various attributes and related functions of the < share > tag. The interface related to the Webkit/Blink to the < share > tag needs to be realized, and support is provided for attributes, methods, events and the like. In an embodiment of the present application, an htmlShareElement element is implemented in the webkit/blink, which is inherited to the htmlelelement, which implements various attributes, related functions and events about the share tag specified in the definition means 11. In addition, support for various events of < share > needs to be added in eventtypenames.in, support for listeners of corresponding events needs to be added in windoweventlandlers.idl and domwindoweventlanders.h, and support for < share > tag event attributes needs to be added in HTMLElement. In addition, html parsers such as html (hypertext markup language) parsers are needed to increase the support of lexical and grammatical parsing of html < share > tags; and adding support for constructing a dom < share > node in htmltreebuilder. Since the < share > node does not need rendering, support in render tree and render layertree, and layout, paint, etc. is not needed. Specifically, implementation of htmlShareElement and its various interfaces: inheriting to the htmlElement, various interfaces defined in the definition apparatus 11 need to be implemented, including related functions, attributes, event attributes, and the like, and specifically, various interfaces defined in the definition apparatus 11 need to be specifically defined in the html share element. html shareelement. cpp, htmlshareelement. h, htmlshareelement. idl need to be placed in the webkit/source/core/html directory of webkit/blink.

More preferably, the first supporting unit 121 is configured to: defining an event name; defining an event handler; and adding support to each event attribute and the corresponding event listener.

Continuing with the above example, htmlshareelement. idl is implemented as follows: event names are defined, specifically various events defined in the above embodiments are added to eventtypeenames. Define event handlers, specifically modify windoweventlandlers. In addition, support for the < share > tag event attribute needs to be added to the HTMLElement. Particularly, the support for various event attributes and the monitor thereof needs to be added in the HTMLelement. And the lexical and grammatical analysis of the < share > tag is realized: the html token, i.e. the html lexical and syntactic parser, needs to add support to the html share tag, including the identification of the tag itself, tag attributes, methods, event attributes, and the like. The DOM share node supports: htmltreebuilder, the DOM tree constructor, needs to add support for constructing DOM share nodes.

Preferably, the communication device 13 comprises: a sending unit (not shown) configured to report the event corresponding to the cross-platform communication function service to a browser page at the client; a receiving unit (not shown) configured to receive a corresponding event from the browser page based on the cross-platform communication network protocol stack, so as to complete a cross-platform communication function service of a server.

In a preferred embodiment of the present application, the sending unit is a Webkit Porting submodule, and the receiving unit is a server/service/manager submodule. After the analysis engine analyzes the < share > tag, the related function of the cross-platform communication service module of the server/service/manager sub-module is called through the Webkit Porting module.

The Webkit Porting module and the Webcore/v8 submodule run in the same process, namely the process where the Web Runtime is located. And the upnp service related to the server/service/manager submodule is operated in another process, so that the Webkit Porting submodule mainly completes the function of communication between processes. Specifically, cross-process communication is mainly realized through a Binder (an inter-process communication mode of the Android is adopted, a BSD open source specification is adopted, and the inter-process communication mode is also adopted in the Bestv TVOS). The Binder realizes the communication between the client and the server based on the remote agent mode. Aiming at the method and the attribute of the < share >, the functions related to the client side are mainly realized at the Webkit Port, and the server side is realized by a server/service/manager cross-platform communication service module. The specific implementation of the relevant interface is as follows, and the specific functional description corresponds to the corresponding method and attribute of < share >:

√bool BpUpnpShareService.address()

√bool BpUpnpShareService.search()

√map<string,string>BpUpnpShareService.deviceList()

√string BpUpnpShareService.deviceInfo(string uuid)

√bool BpUpnpShareService.action(string uuid,string actArg)

√bool BpUPnpShareService.resubscribe(string uuid string type)

√bool BpUpnpShareService.upnpSendMessageAction(string uuid,string message)

√bool BpUpnpShareService.setautoaddress(bool auto)

√bool BpUpnpShareService.setautosearch(bool auto)

√bool BpUpnpShareService.setautobroadcast(bool auto)

√bool BpUpnpShareService.set autobroadcasttime(uint32time)

√bool BpUpnpShareService.setdeviceaborttime(uint32time)

√bool BpUpnpShareService.setautoaddress(bool auto)

aiming at the event of < share >, the related functions of the server side are mainly realized at the Webkit Port side, and finally reported to the related events of the page through the Webcore/v8 submodule, and the related functions of the client side are realized by the server/service/manager cross-platform communication service module, namely the related events are received through the upnp protocol stack. The specific implementation of the relevant interface is as follows, and the specific function corresponds to the event corresponding to the < share >:

√BnUpnpShareEvent.upnpadddevice(string uuid)

√BnUpnpShareEvent.upnpremovdevice(string uuid)

√BnUpnpShareEvent.upnpactionok(string uuid,string action)

√BnUpnpShareEvent.upnpactionerr(string uuid,string action,uint32errcode)

√BnUpnpShareEvent.upnpaction(string uuid,string action)

√BnUpnpShareEvent.resubscribeevnt(string uuid,string event)

√BnUpnpShareEvent.upnpsendmessageactionok(string uuid,string message)

√BnUpnpShareEvent.upnpsendmessageactionerr(string uuid,string message,uint32errcode)

√BnUpnpShareEvent.upnpsendmessageaction(string uuid,string message)

in an embodiment, the server/service/manager submodule implements a cross-platform communication service. The method is specifically completed by upnp service in a server/service/manager submodule, wherein the module runs in an independent process and is started by analyzing an init.rc file through an init process in a Bestv TVOS. Two-part functions of upnp service include control point and device functions. The control point finishes issuing address, search, description and various action commands (such as sendmessage action); the device function completes actions corresponding to various commands, namely responding to address, search, description, various actions and the like of the control point. Aiming at the method and the attribute of the < share >, the related functions of the client are mainly realized at the Webkit Port, the server is realized by a server/service/manager submodule, and the module calls an upnp protocol stack of a Native module to realize the final function. The interfaces to be realized are as follows, and the specific functional description corresponds to the corresponding method and attribute of < share >:

√bool BnUpnpShareService.address()

√bool BnUpnpShareService.search()

√map<string,string>BnUpnpShareService.deviceList()

√string BnUpnpShareService.deviceInfo(string uuid)

√bool BnUpnpShareService.action(string uuid,string actArg)

√bool BnUPnpShareService.resubscribe(string uuid string type)

√bool BnUpnpShareService.upnpSendMessageAction(string uuid,string message)

√bool BnUpnpShareService.setautoaddress(bool auto)

√bool BnUpnpShareService.setautosearch(bool auto)

√bool BnUpnpShareService.setautobroadcast(bool auto)

√bool BnUpnpShareService.set autobroadcasttime(uint32time)

√bool BnUpnpShareService.setdeviceaborttime(uint32time)

√bool BnUpnpShareService.setautoaddress(bool auto)

aiming at the event of < share >, the related functions of a remote agent server side are mainly realized at Webkit Port, the remote agent client side is realized by a server/service/manager submodule, and the module is realized by a callback realized by the upnp protocol stack to realize the final function. The interfaces to be realized are as follows, and the specific functional description corresponds to the event corresponding to the < share >:

√BpUpnpShareEvent.upnpadddevice(string uuid)

√BpUpnpShareEvent.upnpremovdevice(string uuid)

√BpUpnpShareEvent.upnpactionok(string uuid,string action)

√BpUpnpShareEvent.upnpactionerr(string uuid,string action,uint32errcode)

√BpUpnpShareEvent.upnpaction(string uuid,string action)

√BpUpnpShareEvent.resubscribeevnt(string uuid,string event)

√BpUpnpShareEvent.upnpsendmessageactionok(string uuid,string message)

√BpUpnpShareEvent.upnpsendmessageactionerr(string uuid,string message,uint32errcode)

√BpUpnpShareEvent.upnpsendmessageaction(string uuid,string message)

in the embodiment of the application, the network library module of the Native module: and finishing the realization of a cross-platform communication network protocol stack, specifically realizing through libipnp. The Upnp protocol stack is completed using an open-source liboppnp-1.6.19, which follows the GNU/GPL specification.

FIG. 5 illustrates a flowchart of a method for implementing cross-platform communication, in accordance with another aspect of the subject application; the method includes step S11, step S12, step S13, and step S14. Wherein, in step S11, a < share > tag is defined, the tag comprising two or more interfaces; in step S12, each interface in the < share > tag is analyzed to obtain support information of each interface; in step S13, a cross-platform communication network protocol stack between the client and the server is established; in step S14, a cross-platform communication function service between the client and the server is performed according to the cross-platform communication network protocol stack, the interface, and the support information thereof.

The method for realizing cross-platform communication is based on cross-platform communication realized by BesTV TVOS, is used for television services, and comprises ott (Internet television service Over The Top), iptv (Interactive Internet television (Internet television) Internet, dvb (Digital television (Digital Video Broadcasting)), html5(Hyper Text Markup Language 5), network application realized based on hypertext Markup Language 5, and The like. The BesTV TVOS is an operating system implemented based on a webpage, and all applications are essentially implemented based on the webpage. The BesTV TVOS does not implement the window system itself, but rather it is implemented through a web control. The browser functionality in the BesTV TVOS no longer appears as an application, but as a system function. All applications conform to the html5 standard to achieve cross-platform objectives, i.e., to run web applications on other systems that conform to html5 standard functionality. In the embodiments described below in this application, all are performed on the BesTV TVOS architecture. Wherein, the architecture diagram of BesTV TVOS is shown in FIG. 2. In fig. 2, the Webapp part mainly includes Desktop/launcher UI (user interface of Desktop or Desktop application), system app (application), tv app, etc., which are all implemented in a web page form, local page or web page, so as to achieve the purpose of cross-platform; the Web frame module realizes the functions of basic system function, television service, value-added service and the like necessary for the set-top box based on html5 and js (JavaScript, Web scripting language), and the part is divided into three layers, and the total number of the modules is 6: webos api, sdk api (programming interface for software development kit) like andorid; TV frame specifically realizes related functions of TV service and the like; system frame: various system management functions; the server/service/manager realizes various functions of the system, and an ipc (inter-process communication mechanism) mechanism of the system comprises a player function and the like; w3c html/css/js; standard plug-in interfaces, such as npapi (netscape plug in application programming), bho (brown help object), etc. The Web Runtime is realized based on open source blink/v8, is not a simple webkit, v8 function, and needs to comprise four modules: runtime manager function, WebBOM function, Webkit Porting function, Webcore/v8 function. The runtime manager function is management of a module, the WebBOM function realizes a BOM (Browser Object Model) function of w3c, the Webkit Porting realizes a Webkit function including a packaging Webcore and an adaptation platform function, and the Webcore/v8 function follows parsing, layout and rendering engine of html/css/js of GPL specification. Native realizes the function support, mainly includes: audio and video analysis coding and decoding, a graph library, a picture decoding library, a network library, other commonly used necessary function libraries and a JVM (Java virtual machine). The HAL module: an android HAL (Hardware Abstraction Layer) Layer is used to be compatible with android devices while reducing development tasks. The Kernel api: to support different kenel (operating system kernel) that uses linux to perform the kenel level functions.

FIG. 3 illustrates a schematic diagram of a device module for implementing cross-platform communication in a preferred embodiment in accordance with an aspect of the subject application; the equipment module mainly comprises an HTML/CSS/JS API submodule of a Web frame module; a Webcore/v8 sub-module and a Webkit Porting sub-module of the Web Runtime module; a server/service/manager submodule of the Web frame module; and a network library submodule of the Native module. The related HTML/CSS/JS API sub-module is mainly a newly added < share > tag, including the method, attribute and event interface thereof; the Webcore/v8 submodule completes the analysis of the newly added < share > tag, including the analysis of various attributes, methods and events of the < share > tag; the Webkit Porting submodule realizes the calling of a cross-platform communication function service after the resolution engine resolves the newly added < share > tag; the cross-platform communication function service is specifically completed by an upnp service of a server/service/manager submodule, the service is operated in an independent process, and the init is analyzed by an init process in a Bestv TVOS and is started by an init. The network protocol stack required by the upnp service is realized by adding a cross-platform communication upnp network protocol stack to a network sub-module in a native module, and is specifically realized by libipnp. The upnp network protocol stack completes communication with other local area network devices which also support the upnp network protocol stack through http, soap, gena, ssdp and other protocols. The call flow is implemented in the order indicated in fig. 3, and the event implementation process is the reverse. The HTML/CSS/JS API submodule is utilized in step S11, Webcore/v8 is utilized in step S12, a Native module is utilized in step S13, and a Webkit Porting submodule and a server/service/manager submodule are utilized in step S14.

Preferably, in step S11, a correlation function, an attribute and an event of each interface in a < share > tag are defined, wherein the < share > tag is a node in the document object model tree.

Here, in step S13, the corresponding correlation function is executed based on the corresponding event, and the corresponding communication function service is triggered using the corresponding attribute during the execution of the corresponding correlation function.

Preferably, in step S13, according to the timeout setting, the triggering of the corresponding communication function service includes querying a timeout time of another universal plug and play device in the local area network; according to the automatic verification, triggering the corresponding communication function service comprises automatically sending a simple service discovery protocol message; and according to the preset time interval, triggering the corresponding communication function service, including automatically sending a simple service discovery protocol message, and determining the time interval of the simple service discovery protocol message.

More preferably, in step S13, according to the automatic addressing, the corresponding communication function service is triggered to include local universal plug and play device automatic addressing. Here, the local upnp device automatically addresses if the autoaddress attribute is present. More preferably, in step S13, according to the automatic query, the triggering of the corresponding communication function service includes automatically querying other universal plug and play devices in the local area network. Here, if the autosearch attribute occurs, the other upnp devices in the autosearch local area network are automatically searched. More preferably, step S13 further includes: and according to the equipment response, wherein the equipment response is that the equipment response is not received in the time interval, and the triggering of the corresponding communication function service comprises setting automatic suspension of sending messages. Here, the attribute deviceabortime is used for not receiving the device presence message within the time interval of the ssdp presence message issued, and autobroadcast is set to prove the device exception exit.

Preferably, fig. 6 shows a schematic flow chart of step S12 according to a preferred embodiment of another aspect of the present application. The step S12 includes: step S121, step S122, and step S123, wherein in step S121, an interface of the < share > tag is defined in a browser engine, and support information corresponding to the interface is created; in step S122, parsing the lexical and grammatical rules of the < share > tag to obtain support information of the lexical and grammatical rules; in step S123, support information for < share > tag nodes in the constructed document object model tree is created.

Here, the resolution of the newly added < share > tag is completed, including various attributes and related functions of the < share > tag. The interface related to the Webkit/Blink to the < share > tag needs to be realized, and support is provided for attributes, methods, events and the like. In an embodiment of the present application, an htmlShareElement element is implemented in the webkit/blink, which inherits to the htmlElement, which implements various attributes, correlation functions and events for the < share > tag specified in step S11. In addition, support for various events of < share > needs to be added in eventtypenames.in, support for listeners of corresponding events needs to be added in windoweventlandlers.idl and domwindoweventlanders.h, and support for < share > tag event attributes needs to be added in HTMLElement. In addition, html parsers such as html (hypertext markup language) parsers are needed to increase the support of lexical and grammatical parsing of html < share > tags; and adding support for constructing a dom < share > node in htmltreebuilder. Since the < share > node does not need rendering, support in render tree and render layertree, and layout, paint, etc. is not needed. Specifically, implementation of htmlShareElement and its various interfaces: inheriting to the htmlElement, various interfaces defined in step S11 need to be implemented, including related functions, attributes, event attributes, and the like, and specifically, various interfaces defined in step S11 need to be specifically completed by defining the htmlshareelement. html shareelement. cpp, htmlshareelement. h, htmlshareelement. idl need to be placed in the webkit/source/core/html directory of webkit/blink.

More preferably, step S121 includes: defining an event name; defining an event handler; and adding support to each event attribute and the corresponding event listener.

Continuing with the above example, htmlshareelement. idl is implemented as follows: event names are defined, specifically various events defined in the above embodiments are added to eventtypeenames. Define event handlers, specifically modify windoweventlandlers. In addition, support for the < share > tag event attribute needs to be added to the HTMLElement. Particularly, various event attributes and the support of a listener thereof need to be added in the HTMLelement. And the lexical and grammatical analysis of the < share > tag is realized: the html token, i.e. the html lexical and syntactic parser, needs to add support to the html share tag, including the identification of the tag itself, tag attributes, methods, event attributes, and the like. The DOM share node supports: htmltreebuilder, the DOM tree constructor, needs to add support for constructing DOM share nodes.

Preferably, step S13 includes: reporting the event corresponding to the cross-platform communication function service to a browser page at the client; and receiving a corresponding event from the browser page based on the cross-platform communication network protocol stack so as to complete the cross-platform communication function service of the server.

In a preferred embodiment of the present application, after the resolution engine resolves the < share > tag, the server/service/manager submodule is invoked to perform a related function on the cross-platform communication service module through the Webkit Porting module.

√bool BpUpnpShareService.address()

√bool BpUpnpShareService.search()

√map<string,string>BpUpnpShareService.deviceList()

√string BpUpnpShareService.deviceInfo(string uuid)

√bool BpUpnpShareService.action(string uuid,string actArg)

√bool BpUPnpShareService.resubscribe(string uuid string type)

√bool BpUpnpShareService.upnpSendMessageAction(string uuid,string message)

√bool BpUpnpShareService.setautoaddress(bool auto)

√bool BpUpnpShareService.setautosearch(bool auto)

√bool BpUpnpShareService.setautobroadcast(bool auto)

√bool BpUpnpShareService.set autobroadcasttime(uint32time)

√bool BpUpnpShareService.setdeviceaborttime(uint32time)

√bool BpUpnpShareService.setautoaddress(bool auto)

√BnUpnpShareEvent.upnpadddevice(string uuid)

√BnUpnpShareEvent.upnpremovdevice(string uuid)

√BnUpnpShareEvent.upnpactionok(string uuid,string action)

√BnUpnpShareEvent.upnpactionerr(string uuid,string action,uint32errcode)

√BnUpnpShareEvent.upnpaction(string uuid,string action)

√BnUpnpShareEvent.resubscribeevnt(string uuid,string event)

√BnUpnpShareEvent.upnpsendmessageactionok(string uuid,string message)

√BnUpnpShareEvent.upnpsendmessageaction(string uuid,string message)

√bool BnUpnpShareService.address()

√bool BnUpnpShareService.search()

√map<string,string>BnUpnpShareService.deviceList()

√string BnUpnpShareService.deviceInfo(string uuid)

√bool BnUpnpShareService.action(string uuid,string actArg)

√bool BnUPnpShareService.resubscribe(string uuid string type)

√bool BnUpnpShareService.upnpSendMessageAction(string uuid,string message)

√bool BnUpnpShareService.setautoaddress(bool auto)

√bool BnUpnpShareService.setautosearch(bool auto)

√bool BnUpnpShareService.setautobroadcast(bool auto)

√bool BnUpnpShareService.set autobroadcasttime(uint32time)

√bool BnUpnpShareService.setdeviceaborttime(uint32time)

√bool BnUpnpShareService.setautoaddress(bool auto)

√BpUpnpShareEvent.upnpadddevice(string uuid)

√BpUpnpShareEvent.upnpremovdevice(string uuid)

√BpUpnpShareEvent.upnpactionok(string uuid,string action)

√BpUpnpShareEvent.upnpactionerr(string uuid,string action,uint32errcode)

√BpUpnpShareEvent.upnpaction(string uuid,string action)

√BpUpnpShareEvent.resubscribeevnt(string uuid,string event)

√BpUpnpShareEvent.upnpsendmessageactionok(string uuid,string message)

√BpUpnpShareEvent.upnpsendmessageaction(string uuid,string message)

According to yet another aspect of the present application, there is also provided a computing-based device, comprising:

a processor; and

a memory arranged to store computer executable instructions that, when executed, cause the processor to:

defining a < share > tag, the tag comprising two or more interfaces; analyzing each interface in the < share > tag to obtain the support information of each interface; establishing a cross-platform communication network protocol stack between a client and a server; and performing cross-platform communication functional service between the client and the server according to the cross-platform communication network protocol stack, the interface and the support information thereof.

It should be noted that the present application may be implemented in software and/or a combination of software and hardware, for example, implemented using Application Specific Integrated Circuits (ASICs), general purpose computers or any other similar hardware devices. In one embodiment, the software programs of the present application may be executed by a processor to implement the steps or functions described above. Likewise, the software programs (including associated data structures) of the present application may be stored in a computer readable recording medium, such as RAM memory, magnetic or optical drive or diskette and the like. Additionally, some of the steps or functions of the present application may be implemented in hardware, for example, as circuitry that cooperates with the processor to perform various steps or functions.

In addition, some of the present application may be implemented as a computer program product, such as computer program instructions, which when executed by a computer, may invoke or provide methods and/or techniques in accordance with the present application through the operation of the computer. Program instructions which invoke the methods of the present application may be stored on a fixed or removable recording medium and/or transmitted via a data stream on a broadcast or other signal-bearing medium and/or stored within a working memory of a computer device operating in accordance with the program instructions. An embodiment according to the present application comprises an apparatus comprising a memory for storing computer program instructions and a processor for executing the program instructions, wherein the computer program instructions, when executed by the processor, trigger the apparatus to perform a method and/or a solution according to the aforementioned embodiments of the present application.

It will be evident to those skilled in the art that the present application is not limited to the details of the foregoing illustrative embodiments, and that the present application may be embodied in other specific forms without departing from the spirit or essential attributes thereof. The present embodiments are therefore to be considered in all respects as illustrative and not restrictive, the scope of the application being indicated by the appended claims rather than by the foregoing description, and all changes which come within the meaning and range of equivalency of the claims are therefore intended to be embraced therein. Any reference sign in a claim should not be construed as limiting the claim concerned. Furthermore, it is obvious that the word "comprising" does not exclude other elements or steps, and the singular does not exclude the plural. A plurality of units or means recited in the apparatus claims may also be implemented by one unit or means in software or hardware. The terms first, second, etc. are used to denote names, but not any particular order.

Claims

1. A method for enabling cross-platform communication, wherein the method comprises:

defining a < share > tag, the tag comprising two or more interfaces;

according to the cross-platform communication network protocol stack, the interface and the supporting information thereof, carrying out cross-platform communication functional service between the client and the server; wherein the definition < share > tag comprises two or more interfaces, including:

defining related functions, attributes and events of each interface in a < share > tag, wherein the < share > tag is a node in a document object model tree;

the sending unit and the receiving unit are operated in the same process, and the performing of the cross-platform communication function service between the client and the server comprises:

performing, by the sending unit, the steps of: reporting an event corresponding to the cross-platform communication function service to a browser page at the client;

performing, by the receiving unit, the steps of: and receiving a corresponding event from the browser page based on the cross-platform communication network protocol stack so as to complete the cross-platform communication function service of the server.

2. The method of claim 1, wherein performing cross-platform communication function traffic between the client and the server comprises:

the corresponding correlation function is executed based on the corresponding event, and the corresponding communication function service is triggered using the corresponding attribute during the execution of the corresponding correlation function.

3. The method of claim 1 or 2, wherein the correlation function comprises:

an addressing function, a query function, a device list function, a device control function, a device event function, and a device expression function.

4. The method of claim 1 or 2, wherein the event comprises:

adding a device event, removing the device event, overtime inquiry event, state judgment event, abnormal execution device event, execution request event, message sending event, abnormal message reporting event and response event.

5. The method of claim 2, wherein the attributes comprise:

automatic addressing, automatic querying, timeout setting, automatic verification, preset time interval, and device response.

6. The method of claim 5, wherein triggering the respective communication function service with the corresponding attribute comprises:

according to the timeout setting, triggering corresponding communication function service comprises inquiring the timeout time of other universal plug and play devices in the local area network;

according to the automatic verification, triggering the corresponding communication function service comprises automatically sending a simple service discovery protocol message;

and according to the preset time interval, triggering the corresponding communication function service, including automatically sending a simple service discovery protocol message, and determining the time interval of the simple service discovery protocol message.

7. The method of claim 6, wherein triggering the corresponding communication function service with the corresponding attribute further comprises:

and according to the automatic addressing, triggering the corresponding communication function service to comprise the automatic addressing of the local universal plug and play equipment.

8. The method of claim 6, wherein triggering the corresponding communication function service with the corresponding attribute further comprises:

and according to the automatic query, triggering the corresponding communication function service, including automatically querying other universal plug and play devices in the local area network.

9. The method of claim 6, wherein triggering the corresponding communication function service with the corresponding attribute further comprises:

and according to the equipment response, wherein the equipment response is that the equipment response is not received in the time interval, and the triggering of the corresponding communication function service comprises setting automatic suspension of sending messages.

10. The method of claim 1, wherein parsing each interface in the < share > tag to obtain support information of each interface comprises:

defining an interface of the < share > tag in a browser engine, and creating support information corresponding to the interface;

analyzing the lexical method and grammar of the < share > tag to obtain support information of the lexical method and grammar;

creating support information for < share > tag nodes in the document object model tree.

11. The method of claim 10, wherein defining an interface of the < share > tag in a browser engine and creating support information corresponding to the interface comprises:

defining an event name;

defining an event handler;

and adding support to each event attribute and the corresponding event listener.

12. An apparatus for enabling cross-platform communication, wherein the apparatus comprises:

the communication device is used for performing cross-platform communication function business between the client and the server according to the cross-platform communication network protocol stack, the interface and the supporting information thereof;

wherein the defining means is for:

wherein the communication device comprises: a sending unit and a receiving unit running in the same process,

a sending unit, configured to report an event corresponding to a cross-platform communication function service to a browser page at the client;

and the receiving unit is used for receiving a corresponding event from the browser page based on the cross-platform communication network protocol stack so as to complete the cross-platform communication function service of the server.

13. The apparatus of claim 12, wherein the communication device is to:

14. The apparatus of claim 12 or 13, wherein the correlation function comprises:

15. The apparatus of claim 12 or 13, wherein the event comprises:

16. The device of claim 13, wherein the attributes comprise:

17. The apparatus of claim 16, wherein the communication device is to:

18. The apparatus of claim 17, wherein the communication device is further configured to:

19. The apparatus of claim 17, wherein the communication device is further configured to:

20. The apparatus of claim 17, wherein the communication device is further configured to:

21. The apparatus of claim 12, wherein the parsing means comprises:

a first supporting unit, configured to define an interface of the < share > tag in a browser engine, and create supporting information corresponding to the interface;

the second support unit is used for analyzing the lexical method and the grammar of the < share > tag to obtain the support information of the lexical method and the grammar;

and the third supporting unit is used for creating supporting information of the < share > tag node in the document object model tree.

22. The apparatus of claim 21, wherein the first support unit is to:

defining an event name;

defining an event handler;

23. A computer-based device, comprising:

a processor; and

defining a < share > tag, the tag comprising two or more interfaces;

according to the cross-platform communication network protocol stack, the interface and the supporting information thereof, carrying out cross-platform communication functional service between the client and the server;

wherein the definition < share > tag comprises two or more interfaces, including: