CN111726376A

CN111726376A - On-site ticket checking system

Info

Publication number: CN111726376A
Application number: CN201910210010.0A
Authority: CN
Inventors: 石同享
Original assignee: Alibaba Group Holding Ltd
Current assignee: Alibaba Group Holding Ltd
Priority date: 2019-03-19
Filing date: 2019-03-19
Publication date: 2020-09-29
Anticipated expiration: 2039-03-19
Also published as: CN111726376B

Abstract

The invention discloses a field ticket checking system, which comprises a local server and a plurality of ticket checking terminals; each ticket checking terminal and the local server are configured to be nodes in a peer-to-peer network, and each node is connected with at least one other node; the local server is configured to connect to a ticketing data center via a wide area network; each node propagates respective ticketing data in the peer-to-peer network, the ticketing data including: the method comprises the steps that a local server obtains first ticketing data from a ticketing data center; and each ticket checking terminal checks the ticket checking data obtained by the experience ticket according to the first ticket data of each ticket checking terminal to generate second ticket data.

Description

On-site ticket checking system

Technical Field

The invention relates to the technical field of communication, in particular to a field ticket checking system.

Background

With the development of science and technology, more and more ticket checking places (such as stations, cinemas, concerts and the like) realize ticket checking by building a ticket checking system on site instead of a traditional manual ticket checking mode, so that the ticket checking efficiency and the ticket checking accuracy are improved.

When an existing ticket checking system builds a local area network on site, one or more of a local server, a Wireless Access Point (AP) device and a router need to be used as a central node to realize data synchronization among multiple ticket checking terminals, so as to avoid the problem that different users can enter the field for multiple times by means of the same ticket.

In the existing ticket checking system, because at least one central node exists in the local area network, if any central node fails, the normal operation of the ticket checking system is affected, for example, when the AP device is used to connect at least one ticket checking terminal, the AP device becomes the central node of all the ticket checking terminals connected thereto, so that if the AP device fails, all the ticket checking terminals connected thereto cannot complete the ticket checking operation; for another example, when a local area network is constructed by connecting a plurality of AP devices using a router, the router will be a central node of the AP device connected thereto, so that if the router fails, all ticket checking terminals in the whole ticket checking system cannot complete the ticket checking operation. For another example, the local server is used as a central node of the whole ticket checking system and is responsible for being connected with a ticket data center through a wide area network to provide ticket data required by ticket checking for the ticket checking terminal, and when the local server fails, all ticket checking terminals in the whole ticket checking system cannot complete ticket checking operation.

Therefore, for the existing ticket checking system, once a central node in the local area network fails, problems of personnel detention, repeated entry of personnel and the like in a local or whole ticket checking area occur, and therefore, a new field ticket checking system is very needed to be provided to improve the fault resistance of the local area network.

Disclosure of Invention

The embodiment of the invention aims to provide a novel on-site ticket checking system.

According to a first aspect of the embodiments of the present invention, there is provided an on-site ticket checking system, which includes a local server and a plurality of ticket checking terminals; each ticket checking terminal and the local server are configured to be nodes in a peer-to-peer network, and each node is connected with at least one other node; the local server is configured to connect to a ticketing data center via a wide area network;

each node propagates in the peer-to-peer network respective ticketing data comprising:

the local server acquires first ticketing data from the ticketing data center; and the number of the first and second groups,

and each ticket checking terminal checks the ticket checking data obtained by the experience ticket according to the first ticket data of the ticket checking terminal to generate second ticket data.

Optionally, the local server is further configured to upload the second ticketing data obtained from the ticket checking terminal to the ticketing data center, so that the ticketing data center updates the first ticketing data according to the second ticketing data.

Optionally, each node is further configured to update the first ticket data stored in the node itself according to the second ticket data obtained by the node.

Optionally, the local server is configured to: and acquiring the first ticket data from the ticket data center in response to a set acquisition event.

Optionally, the set acquisition event includes any one or more of the following: when the set time interval is up, newly establishing communication connection with the ticket data center, and receiving an update notification sent by the ticket data center according to the update of the first ticket data.

Optionally, the local server is further configured to:

providing a first setting entrance for setting the acquisition event;

acquiring an acquisition event input through the first setting entrance;

and updating the set acquisition event as the input trigger event.

Optionally, each of the nodes propagates respective ticket data in the peer-to-peer network, including:

each node searches other nodes which can be connected with the node in the peer-to-peer network to serve as respective target nodes;

and each node sends the ticket data which each node has to the target node.

Optionally, each of the first ticket data and the second ticket data has a unique data identifier; the nodes propagate the ticket data in the peer-to-peer network, including:

each node sends the data identification of the ticket data to other nodes which can be connected in the peer-to-peer network;

each node compares the data identification of the ticket data with the data identification sent by other nodes to obtain the data identification lacking in other nodes;

and each node sends the ticket data marked by the data identification lacking in the other nodes to the corresponding other nodes.

each node propagates ticket data in the peer-to-peer network according to a set trigger event;

optionally, the trigger event includes any one or more of the following: acquiring new ticket data, changing other nodes capable of being connected, and detecting that a new node joins the peer-to-peer network.

Optionally, each node is configured to:

providing a second setting entry for setting the triggering event;

acquiring a trigger event input through the second setting entrance;

and updating the set trigger event to be the input trigger event.

Optionally, the ticket checking terminal is further configured to check the obtained ticket checking data according to the first ticket data of the ticket checking terminal, so as to generate a check result, and prompt the check result.

Optionally, the second ticketing data includes any one or a combination of the following data: ticket number, ticket checking time, ticket checking terminal identification, check-in identification/check-out identification.

Optionally, the peer-to-peer network is an ad hoc network, and each node is provided with an ad hoc module.

The on-site ticket checking system provided by the embodiment of the invention configures the local server and the ticket checking terminals included in the on-site ticket checking system as nodes in a peer-to-peer network, so that no central node exists in the local server and the ticket checking terminals. Meanwhile, ticket data of each node in the peer-to-peer network is propagated in the peer-to-peer network, and ticket checking operation can be completed. That is to say, on the one hand, the field ticket checking system provided by the embodiment of the invention can avoid the problem that the ticket checking operation cannot be completed by the ticket checking terminal connected with the central node when the central node fails due to the existence of the central node. On the other hand, AP equipment is avoided being erected, and therefore complexity and cost of building the on-site ticket checking system are reduced.

Other features of the present invention and advantages thereof will become apparent from the following detailed description of exemplary embodiments thereof, which proceeds with reference to the accompanying drawings.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings required to be used in the embodiments will be briefly described below. It is appreciated that the following drawings depict only certain embodiments of the invention and are therefore not to be considered limiting of its scope. For a person skilled in the art, it is possible to derive other relevant figures from these figures without inventive effort.

FIG. 1 is a schematic configuration diagram of a venue according to an embodiment of the present invention;

FIG. 2 is a schematic structural diagram of a networking architecture of a field ticket checking system;

fig. 3 is a schematic structural diagram of a networking architecture of another field ticket checking system.

Fig. 4 is a schematic structural diagram of an on-site ticket checking system provided by an embodiment of the invention;

fig. 5 is a schematic structural diagram of a local server according to an embodiment of the present invention;

fig. 6 is a schematic structural diagram of a ticket checking terminal according to an embodiment of the present invention;

fig. 7 is an interaction diagram of data synchronization between nodes according to an embodiment of the present invention.

Detailed Description

Various exemplary embodiments of the present invention will now be described in detail with reference to the accompanying drawings. It should be noted that: the relative arrangement of the components and steps, the numerical expressions and numerical values set forth in these embodiments do not limit the scope of the present invention unless specifically stated otherwise.

The following description of at least one exemplary embodiment is merely illustrative in nature and is in no way intended to limit the invention, its application, or uses.

Techniques, methods, and apparatus known to those of ordinary skill in the relevant art may not be discussed in detail but are intended to be part of the specification where appropriate.

In all examples shown and discussed herein, any particular value should be construed as merely illustrative, and not limiting. Thus, other examples of the exemplary embodiments may have different values.

It should be noted that: like reference numbers and letters refer to like items in the following figures, and thus, once an item is defined in one figure, further discussion thereof is not required in subsequent figures.

Fig. 1 is a schematic configuration diagram of a venue to which the on-site ticket checking system is applied.

Referring to fig. 1, in order to ensure that the spectators can enter the event by checking tickets when the event is carried out, such as a concert or a sporting event, a plurality of ticket checking terminals 200 are installed in the venue to check tickets on the spot at the same time, so as to ensure that thousands of people can enter the event in an orderly manner. Here, the ticket checking terminal 200 may be a fixed ticket checking terminal, such as a gate, or a portable mobile ticket checking terminal, such as a PDA, etc., and the plurality of ticket checking terminals configured in the venue shown in fig. 1 may be the same type of ticket checking terminal, such as a fixed ticket checking terminal or a mobile ticket checking terminal, or may include different types of ticket checking terminals, such as a fixed ticket checking terminal and a mobile ticket checking terminal.

Referring to the schematic view of the venue shown in fig. 1, the venue has three entrances, namely a first entrance, a second entrance and a third entrance, through which the spectators can enter before the performance starts, so that the operator needs to configure at least one ticket checking terminal at each entrance, so as to check the tickets provided by the spectators entering the venue through the ticket checking terminal at each entrance, and if the tickets pass, the spectators are allowed to enter the venue for sitting, and if the tickets do not pass, the spectators are prohibited from entering the venue.

With the ticket checking system provided with a plurality of ticket checking terminals 200 as shown in fig. 1, at the time of checking a ticket, each ticket checking terminal 200 needs to acquire first ticket data generated by ticketing so that each ticket checking terminal 200 can perform on-site ticket checking based on the first ticket data, and each ticket checking terminal 200 will generate second ticket data through on-site ticket checking.

Each first ticket data may include the following information: any one or more of ticket number, event name, field, time of departure, seat number, and status (e.g., sold, unsubscribed, unchecked, and checked). Each first ticket data corresponds to a unique ticket, and the ticket number of each ticket is unique. Taking the ticket as the movie ticket as an example, the first ticket data includes: ticket number, movie name, play field, opening time, movie hall label, seat number, sold/unsubscribed logo, checked/unchecked logo, etc. Here, it should be noted that the information included in the first ticketing data relates to a specific ticket checking scenario, and the specific information included in the first ticketing data is not limited in the embodiment of the present invention.

When the ticket checking terminal 200 checks the ticket, the two-dimensional code or the barcode on the ticket can be scanned to obtain the ticket checking data corresponding to the identifier. For example, the ticket validation data may include: ticket number, opening time, ticket gate, time, event name, seat number, etc.

After the ticket checking terminal 200 obtains the ticket checking data, the ticket checking data obtained from the experience ticket can be checked according to the obtained first ticket business data, and if the check is passed, the second ticket business data is generated.

Each second ticketing data may include any or a combination of the following: ticket number, ticket checking time, ticket checking terminal identification, check-in identification/check-out identification and the like. The second ticketing data may be used to update the first ticketing data, e.g., to update the status of the first ticketing data as verified based on the second ticketing data, etc.

The first ticketing data can be provided by a ticketing data center located at the cloud end, for example, therefore, a networking structure of the on-site ticketing system needs to support that all the ticketing terminals 200 can obtain the first ticketing data provided by the ticketing data center, a local server can be set to build a local area network, the local server is connected with the ticketing data center to obtain the first ticketing data, and the local server provides the first ticketing data for the ticketing terminals through the local area network to check tickets.

Furthermore, since each ticket checking terminal 200 performs the ticket checking operation independently and generates the second ticket data, in order to avoid the problem that a plurality of users enter the field multiple times through the same ticket, the networking structure of the on-site ticket checking system needs to support each ticket checking terminal 200 to obtain the second ticket data generated by other ticket checking terminals for data synchronization.

Based on the networking requirements, an existing field ticket checking system is shown in fig. 2, and the networking structure of the field ticket checking system is a single-router networking, and includes a plurality of ticket checking terminals 200, a router 400 and a local server 100, the local server 100 is connected with a ticketing data center 300 through a wide area network to obtain first ticketing data, each ticket checking terminal 200 is connected with the local server 100 through the router 400 to upload second ticketing data generated by ticket checking to the local server 100 on one hand, and on the other hand, the first ticketing data and the second ticketing data of the local server 100 are obtained. The field ticket checking system has the problem that the field ticket checking system cannot meet the requirement of a large-scale event project on ticket checking because the wifi signal coverage range of a single router is limited. In addition, for this kind of field ticket checking system, since the router 400 and the local server 100 both belong to the central node, if any one of the central nodes fails, the whole field ticket checking system will be disabled.

In order to solve the problem of insufficient coverage capability of the field ticket checking system shown in fig. 2, another existing field ticket checking system is shown in fig. 3, and the field ticket checking system includes a plurality of Wireless Access Point (AP) devices 500, each AP device 500 corresponds to one venue partition and is respectively connected to at least one ticket checking device 200 corresponding to the venue partition, and the AP devices 500 may be bridged and finally access to the router 400, so as to implement connection between each AP device 400 and the local server 100, thereby constructing a large local area network whose coverage range is proportional to the number of AP devices. Although the on-site ticket checking system has a large coverage range and can meet the ticket checking requirement of a large-scale event site, a plurality of central nodes including AP (access point) equipment, a router and a local server exist, so that the on-site ticket checking system still has the problem of weak fault resistance.

The embodiment of the invention provides a field ticket checking system as shown in fig. 4 in order to solve the problem that the field ticket checking system has poor fault resistance, and meanwhile, the field ticket checking system can obtain the coverage range which can be realized by the field ticket checking system as shown in fig. 2, and meets but is not limited to the ticket checking requirement of a large-scale event field. Fig. 4 schematically illustrates an on-site ticket checking system provided by the embodiment of the present application, which specifically includes a local server 100 and a plurality of ticket checking terminals 200. Each ticket checking terminal 200 and the local server 100 are configured as nodes in a peer-to-peer network, and each node is connected with at least one other node, and the connection may be a wireless connection or a wired connection, which is not limited herein.

In this embodiment, the local server 100 provides a service point for processing, database, and communication facilities. The local server 100 may be a unitary server or a distributed server across multiple computers or computer data centers. The server may be of various types, such as, but not limited to, a web server, a news server, a mail server, a message server, an advertisement server, a file server, an application server, an interaction server, a database server, or a proxy server. In some embodiments, the server may include hardware, software, or embedded logic components or a combination of two or more such components for performing the appropriate functions supported or implemented by the server. For example, a server, such as a blade server, a cloud server, etc., or may be a server group consisting of a plurality of servers, which may include one or more of the above types of servers, etc.

In one example, the local server 100 may be as shown in fig. 5, including a processor 110, a memory 120, an interface device 130, a communication device 140, a display device 150, and an input device 160.

The processor 110 may be, for example, a central processing unit CPU, a microprocessor MCU, or the like. The memory 120 includes, for example, a ROM (read only memory), a RAM (random access memory), a nonvolatile memory such as a hard disk, and the like. The interface device 130 includes, for example, a USB interface, a serial interface, an infrared interface, and the like. The communication device 140 is capable of wired or wireless communication, for example. The display device 150 is, for example, a liquid crystal display, an LED display touch panel, or the like. The input device 160 may include, for example, a touch screen, a keyboard, and the like.

Although a plurality of devices of the server are shown in fig. 5, the present invention may only relate to some of the devices, including, for example, the processor 110, the memory 120, and the communication device 140.

The ticket checking terminal 200 may be a gate, a scanning gun, a PDA (Personal Digital Assistant), a mobile phone, a tablet computer, a palm computer, a wearable device, or the like.

As shown in fig. 6, the ticketing terminal 200 can include a processor 210, a memory 220, an interface device 230, a communication device 240, a display device 250, an input device 260, a speaker 270, a microphone 280, and so forth.

Processor 210 may be a central processor, a portable version processor, or the like. The memory 220 includes, for example, a ROM (read only memory), a RAM (random access memory), a nonvolatile memory such as a hard disk, and the like. The interface device 230 includes, for example, a USB interface, a headphone interface, and the like. The communication device 240 can perform wired or wireless communication, for example, the communication device 240 may include a short-range communication device, such as any device performing short-range wireless communication based on short-range wireless communication protocols, such as the Hilink protocol, WiFi (IEEE 802.11 protocol), Mesh, bluetooth, ZigBee, Thread, Z-Wave, NFC, UWB, LiFi, and the like, and the communication device 240 may also include a long-range communication device, such as any device performing WLAN, GPRS, 2G/3G/4G/5G long-range communication. The display device 250 is, for example, a liquid crystal display panel, a touch panel, or the like. The input device 260 may include, for example, a touch screen, a keyboard, and the like. The ticket checking terminal 200 may output voice information through the speaker 270. The ticket checking terminal can obtain voice information input from the outside through the microphone 280.

Although a plurality of devices of the ticketing terminal 200 are shown in fig. 6, the present invention may relate to only some of the devices, for example, the ticketing terminal 200 only relates to the memory 220 and the processor 210, the communication device 240 and the display device 250.

For the above ticket checking terminal 200, fig. 4 shows the ticket checking terminal 200-1, the ticket checking terminal 200-2, the ticket checking terminal 200-3, the ticket checking terminal 200-4, the ticket checking terminal 200-5, and the ticket checking terminal 200-6. Here, it should be noted that, in practical applications, the number of the ticket checking terminals 200 in the on-site ticket checking system may be determined according to actual requirements, for example, the number of the ticket checking terminals 200 may be determined according to entrance setting conditions of a venue, which is not limited in the embodiment of the present disclosure.

In one example, 5 ticket checking terminals 200 can be provided for each entrance of the venue when the local area network is established, wherein the distance between two adjacent entrances does not exceed 100 meters generally. For example, for ticket checking places (e.g., a gym, a movie theater, a museum, etc.) capable of accommodating ten thousand people, 2 to 3 entrances are usually provided, and 10 to 15 ticket checking apparatuses 200 can be configured accordingly. For another example, for a field management of 10 ten thousand people, the number of entrances of a venue is generally not more than 10, and the ticket checking requirement can be met by preparing 50 ticket checking terminals 200.

In this embodiment, the peer-to-peer network is a network architecture without a central node, and nodes connected to each other are in a peer-to-peer status without a master-slave role, and each node is both a provider of data resources and an acquirer of data resources.

Illustratively, the peer-to-peer network may be an ad hoc network, or a wireless Mesh network. For an adhoc network, each node in the peer-to-peer network can act as an ordinary network node to complete data processing operation, and also can act as a router to realize data forwarding, and wireless connection among the nodes can be conveniently realized.

Taking a peer-to-peer network as an adhoc network as an example, when a local server 100 and a plurality of ticket checking terminals 200 included in a field ticket checking system are configured as nodes in the adhoc network, an adhoc module needs to be arranged in the local server 100 and the plurality of ticket checking terminals 200, and then the adhoc module is started. It should be noted that how to configure the local server 100 and the plurality of ticket checking terminals 200 as nodes in an ad hoc network is easy for those skilled in the art to do. In this regard, the present embodiment will not be further described.

When the local server 100 and each ticket checking terminal 200 are set as nodes in a peer-to-peer network, each node will have a certain communication coverage and establish connection with other nodes within the respective communication coverage. This shows that, for the on-site ticket checking system of this embodiment, when two nodes in the peer-to-peer network are within the communication coverage of each other, the two nodes can directly establish a connection for data synchronization; if two nodes in the peer-to-peer network are not within the communication coverage of each other (e.g., the two nodes are physically far apart), the two nodes may be indirectly connected through other nodes, that is, data forwarding is performed through other nodes, so as to achieve data synchronization between all the nodes.

In practical application, the respective communication coverage range can be set according to the distribution situation of each node in the peer-to-peer network. Taking a peer-to-peer network as an ad hoc network as an example, the communication coverage of each node in the peer-to-peer network is as follows: a circular area centered on the node and having a radius R, where R is related to the power of the adhoc modules in the node, the greater the power of the adhoc modules, the greater R.

It should be further noted that, in order to enable the field ticket checking system provided in this embodiment to establish an adhoc network without partitions, the power of the adhoc module in the node in the adhoc network may be detected and adjusted. When detecting, two nodes in an arbitrary adhoc network are required to meet the following conditions: determining m routing paths between the two selected nodes; for m routing paths, respectively calculating the distance value between every two adjacent nodes in each routing path, and screening out the maximum distance values L1, L2 and … … Lm between the adjacent nodes in each path; selecting the minimum value Lmin (L1, L2 and … … Lm) of L1, L2 and … … Lm as the optimal path distance value of the two nodes; and judging whether the radius of a communication coverage range corresponding to the current power of the adhoc modules of the two nodes is larger than the optimal path distance value Lmin (L1, L2 and … … Lm), if so, determining that the on-site ticket checking system can establish a partition-free adhoc network, otherwise, adjusting the power of the adhoc modules of the corresponding nodes until the conditions are met.

Furthermore, in the embodiment where the peer-to-peer network is an ad hoc network, since the local server 100 and the ticket checking terminal 200 are both configured to be nodes in the ad hoc network, the local server 100 and the ticket checking terminal 200 both have data processing capability and routing capability.

In the present embodiment, as shown in fig. 4, the local server 100 is configured to be connected to the ticketing data center 300 via a wide area network, so that the local server 100 can obtain the first ticketing data from the ticketing data center.

The ticketing data center can be a remote server or a cloud server group.

The ticketing data center 300 stores therein a plurality of first ticketing data, each of which may include the following information: any one or more of ticket number, event name, field, time of departure, seat number, and status (e.g., sold, unsubscribed, unchecked, and checked), and each first ticket data corresponds to a unique ticket, and the ticket number of each ticket is unique. In one embodiment, the stored first ticketing data of the ticketing data center 300 can be updated in real time, for example, if some tickets are sold before the concert is started, the first ticketing data of the tickets can be updated and the sold identifiers can be added.

Taking the ticket as the movie ticket as an example, the first ticket data includes: ticket number, movie name, play field, opening time, movie hall label, seat number, sold/unsubscribed logo, checked/unchecked logo, etc.

It should be noted that the information included in the first ticketing data is related to a specific ticket checking scenario, and the specific information included in the first ticketing data is not limited in the embodiment of the present invention.

In one embodiment, the local server 100 may be further configured to: the first ticket data is acquired from the ticket data center 300 in response to the set acquisition event.

The set acquisition event may include any one or more of the following: when the set time interval is up, newly establishing communication connection with the ticket data center, and receiving an update notification sent by the ticket data center according to the update of the first ticket data.

For example, the set time interval may be 10 min. That is, every 10min, the local server 100 acquires the first ticketing data again from the ticketing data center 300. It should be noted that the set time interval may be an interval of other time lengths, which is not limited in this embodiment.

Illustratively, in an actual ticket checking scenario, after the peer-to-peer network is established, the local server 100 establishes a connection with the ticketing data center 300 through the wide area network according to the setting, and the first connection between the two is a newly established communication connection with the ticketing data center 300. In addition, when the wide area network is unstable, the communication between the local server 100 and the ticketing data center 300 may be disconnected, so that when the wide area network is stabilized again, the local server 100 and the ticketing data center 300 may reestablish a communication connection, which is also the newly established communication connection with the ticketing data center. In the above case where the local server 100 newly establishes a communication connection with the ticketing data center 300, the local server 100 center will retrieve the first ticketing data from the ticketing data center 300.

Illustratively, in an actual ticket checking scene, there is an action of continuing to sell tickets or temporarily returning tickets at any time, which will result in updating the first ticketing data in the ticketing data center 300. In order to avoid that a newly sold legal ticket is not verified when verified by the ticket verifying terminal 200, or a returned ticket is verified successfully, the ticketing data center 300 needs to send an update notification when the first ticketing data in the ticketing data center is updated, so that the local server 100 obtains the first ticketing data from the ticketing data center 300 again.

To meet the personalized needs of the user, in one embodiment, the on-site ticketing system as shown in fig. 4 may support modifications to the above-described acquisition events. In this embodiment, the local server 100 may be further configured to: providing a first setting entrance for setting the acquisition event; acquiring an acquisition event input through a first set entry; and updating the set acquisition event as an input trigger event.

In this embodiment, each node propagates the respective ticket data in the peer-to-peer network, where the ticket data includes not only the first ticket data acquired by the local server 100 from the ticket data center 300 described above, but also the second ticket data generated by verifying the ticket verification data obtained by the experience ticket by each ticket verification terminal 200 according to the respective ticket data, so that the ticket data can be synchronized in the peer-to-peer network, and the ticket data of each node in the peer-to-peer network can achieve final consistency.

When each ticket checking terminal 200 checks the ticket checking data obtained from the experience ticket according to the ticket service data of each ticket checking terminal 200, and further generates second ticket service data, the ticket checking terminal 200 may scan the two-dimensional code or barcode and other identifiers on the ticket to obtain the encrypted character string corresponding to the identifier, and decrypt the encrypted character string to obtain the ticket checking data, where the ticket checking data may include: ticket number, opening time, ticket gate, time, event name, seat number, etc.

After the ticket checking terminal 200 obtains the ticket checking data, the ticket checking data obtained from the experience ticket is checked according to the first ticket data stored in the ticket checking terminal to generate second ticket data. For example, the ticket checking terminal 200 first determines whether the ticket number in the ticket checking data is consistent with the ticket number of a certain piece of first ticket data; if yes, further determining whether the state in the first ticket business data consistent with the ticket number in the ticket checking data is sold and not checked; if yes, adding a checked-out/check-in identifier in the first ticket data, and further adding information such as ticket checking time, a ticket checking port identifier, a ticket checking terminal 200 identifier and the like to generate corresponding second ticket data. This means that the second ticketing data may include any or a combination of the following: ticket number, ticket checking time, ticket checking terminal identification, check-in identification/check-out identification.

It should be noted that when the ticket checking terminal 200 determines that the ticket numbers in the ticket checking data are not consistent with the ticket numbers of all the first ticket data, the ticket checking terminal 200 does not generate the second ticket data.

In one embodiment, in order to enable the staff to intuitively determine which tickets are passable tickets and which tickets are impassable tickets, the ticket checking terminal 200 is further configured to check the obtained ticket checking data according to the first ticketing data to generate a check result and prompt the check result in the process of checking the ticket checking data obtained from the experience ticket according to the first ticketing data to generate second ticketing data.

In this embodiment, the ticket checking terminal 200 may determine whether the ticket number in the ticket checking data is consistent with the ticket number of a certain piece of first ticket data, and if so, generate the ticket corresponding to the ticket checking data as the checking result of the legal ticket. Otherwise, generating a check result that the ticket corresponding to the ticket checking data is an illegal ticket, and indicating that the check fails. It should be noted that the check result of the legal ticket does not necessarily indicate that the check is successful, the ticket checking server may further perform the check through the ticket checking data and other information in the first ticket data, and when all preset check items are passed, the check is successful.

Further, when the ticket number in the ticket checking data is consistent with the ticket number in the first ticket business data, whether the ticket checking data is checked is judged. If the ticket is verified, generating a verification result that the ticket verification data is the verified legal ticket.

It should be noted that, the check of the ticket checking data by the ticket checking server is related to the actual ticket checking environment, and correspondingly, the check result is also related to the actual ticket checking environment, which is easily understood by those skilled in the art.

After the ticket checking terminal 200 generates the checking result, the checking result is prompted. In one example, the ticket checking terminal 200 makes corresponding sound or light prompts to the user according to different checking results. For example, when the check result is that the ticket corresponding to the ticket checking data is the check result of the legal ticket, the voice of' the legal ticket can be output, or a green LED lamp is turned on to prompt the user that the ticket is the legal ticket and can pass. For example, when the check result is that the ticket corresponding to the ticket checking data is an illegal ticket, an alarm sound can be sent out, or a red LED lamp is turned on to prompt the user that the ticket is an illegal ticket and cannot pass through.

In this embodiment, each node propagates the ticket data in the peer-to-peer network, which can be implemented in at least the following ways:

the first method is as follows: each node searches other nodes which can be connected with the node in the peer-to-peer network to serve as respective target nodes; each node sends the ticket data which each node has to the respective target node.

The first method will be described by taking an example of nodes propagating respective first ticket data.

The local server 100 as a peer-to-peer network node acquires first ticket data from a ticket data center; the local server 100 searches the ticket checking terminals 200 which can be connected with the local server as peer-to-peer network nodes, for example, the local server 100 searches the ticket checking terminals which can be connected with the local server as the ticket checking terminal 200-3, the ticket checking terminal 200-4, the ticket checking terminal 200-5 and the ticket checking terminal 200-6, at this time, the local server 100 takes the ticket checking terminal 200-3, the ticket checking terminal 200-4, the ticket checking terminal 200-5 and the ticket checking terminal 200-6 as its target nodes, and sends the first ticket service data to the ticket checking terminal 200-3, the ticket checking terminal 200-4, the ticket checking terminal 200-5 and the ticket checking terminal 200-6, respectively.

After the ticket checking terminal 200-3, the ticket checking terminal 200-4, the ticket checking terminal 200-5 and the ticket checking terminal 200-6 acquire the first ticket data, the ticket checking terminal 200-3, the ticket checking terminal 200-4, the ticket checking terminal 200-5 and the ticket checking terminal 200-6 respectively search the ticket checking terminal 200 which can be connected with the ticket checking terminal to serve as respective target nodes, and respectively send the first ticket data to the respective target nodes.

In the above process, there is a case where one node receives the same first ticket data a plurality of times. In this case, each node may be configured to retain the first ticket data received most recently, or may be configured to compare the first ticket data received a plurality of times and retain the latest first ticket data.

The first method is described by taking the example that the nodes propagate the second ticket data of the respective nodes.

In one example, after the ticket checking terminal 200-1 generates the second ticket data, the ticket checking terminal 200-1 searches the ticket checking terminal 200 and/or the local server 100 which can be connected to itself as a peer-to-peer network node, for example, the ticket checking terminal 200-1 searches the ticket checking terminal 200-3 and the local server 100 which can be connected to itself, at this time, the ticket checking terminal 200-1 uses the ticket checking terminal 200-3 and the local server 100 as its target nodes, and sends the second ticket data to the ticket checking terminal 200-3 and the local server 100, respectively. Meanwhile, the ticket checking terminal 200 and/or the local server 100 also generate second ticket data, respectively.

The ticket checking terminal 200-3 and the local server 100 respectively search the ticket checking terminal 200 which can be connected with themselves to serve as respective target nodes, and respectively send the second ticket data which are respectively provided with the ticket checking terminal to the respective target nodes, namely, the second ticket data received from the ticket checking terminal 200-1 and the second ticket data generated by the local server are respectively sent to the respective target nodes. It should be noted that the ticket checking terminal 200-3 and/or the local server 100 may also receive the second ticket data sent by other ticket checking terminals.

The second method comprises the following steps: each first ticket data and each second ticket data have unique data identification; each node propagates the respective ticket data in the peer-to-peer network, which may include: each node sends the data identification of the ticket data to other nodes which can be connected in the peer-to-peer network; each node compares the data identification of the ticket data with the data identification sent by other nodes to obtain the data identification lacking in other nodes; and each node sends the ticket data marked by the data identification lacking from other nodes to the corresponding other nodes.

Illustratively, the data identification may include: generating node identification corresponding to the ticket data and generating order identification corresponding to the ticket data.

For example, the ticketing data center 300 marks the initial first ticketing data as 300-0, the first updated ticketing data as 300-1, and so on. As another example, the ticket verifying device 200-1 marks the second ticketing data generated via the first ticket verification as 200-1-1, the second ticketing data generated via the second ticket verification as 200-1-2, and so on.

The above-mentioned second method is explained by taking an example in which the data identifier includes a generation node identifier and a generation order identifier of the ticket data.

Referring to fig. 7, taking the ticket checking terminal 200-1 and the ticket checking terminal 200-2 as an example, which are located in the communication coverage of each other, the ticket checking terminal 200-1 and the ticket checking terminal 200-2 each maintain a data list, the data list of the ticket checking terminal 200-1 has the first ticketing data marked by the identifier 300-1, the second ticketing data marked by identification 200-1-1, and the second ticketing data marked by identification 200-3-1, and the data list of the ticket checking terminal 200-2 has the first ticket data marked by the identifier 300-1 and the second ticket data marked by the identifier 200-2-1, for this, the ticket checking terminal 200-2 and the ticket checking terminal 200-1 may perform the following interaction for data synchronization:

step S2201, the ticket checking terminal 200-2 sends the data identification of the ticket data, namely the identification 300-1 and the identification 200-2-1, to the ticket checking terminal 200-1 through the peer-to-peer network.

Step S2101, the ticket checking terminal 200-1 compares the data identification of the ticket data with the ticket checking terminal 200-2, and obtains the data identification which is lacked by the ticket checking terminal 200-2, wherein the data identification comprises an identification 200-3-1 and an identification 200-1-1.

In step S2102, the ticket checking terminal 200-1 transmits the identifier 200-3-1 and the ticket data marked by the identifier 200-1-1 to the ticket checking terminal 200-2.

In step S2202, the ticket checking terminal 2002, after receiving the ticket data sent by the ticket checking terminal 200-1, may update its own data list, where the data list will have the first ticket data marked by the identifier 300-1 and the second ticket data marked by the identifiers 200-2-1, 200-1-1, and 200-3-1.

Similarly, the ticket checking terminal 200-1 can also send the data identifier of the ticket data, namely the identifier 300-1, the identifier 200-1-1 and the identifier 200-3-1, of the ticket checking terminal 200-1 to the ticket checking terminal 200-2 through the peer-to-peer network, the ticket checking terminal 200-2 compares the data identifier of the ticket data of the ticket checking terminal 200-2 with the data identifier sent by the ticket checking terminal 200-1 to obtain the data identifier which is lacked by the ticket checking terminal 200-1 and comprises the identifier 200-2-1, and therefore the ticket checking terminal 200-2 can send the ticket data marked by the identifier 200-2-1 to the ticket checking terminal 200-1. Therefore, based on the second mode, each node in the peer-to-peer network finally obtains completely consistent ticket data, and synchronization of the ticket data is realized.

The third method comprises the following steps: each first ticket data and each second ticket data have unique data identification; each node propagates the respective ticket data in the peer-to-peer network, which may include: each node sends the data identification of the ticket data to other nodes which can be connected in the peer-to-peer network; each node compares the data identification of the ticket data with the data identification sent by other nodes to obtain the data identification lacking in the node; each node sends a data acquisition request containing the data identifier lacking per se to other nodes according to the data identifier lacking per se; and each node provides corresponding ticket data to the node sending the data acquisition request according to the received data acquisition request.

The local server 100 as a peer-to-peer network node acquires first ticketing data identified as 300-1 from a ticketing data center; the local server 100 searches the ticket checking terminal 200 which can be connected with itself and is a peer-to-peer network node, for example, the local server 100 searches the ticket checking terminals 200 which can be connected with itself as the ticket checking terminal 200-3, the ticket checking terminal 200-4, the ticket checking terminal 200-5 and the ticket checking terminal 200-6, at this time, the local server 100 takes the ticket checking terminal 200-3, the ticket checking terminal 200-4, the ticket checking terminal 200-5 and the ticket checking terminal 200-6 as its target nodes and sends the identifier 300-1 to the ticket checking terminal 200-3, the ticket checking terminal 200-4, the ticket checking terminal 200-5 and the ticket checking terminal 200-6 respectively.

After receiving the identifier 300-1, the ticket checking terminal 200-3, the ticket checking terminal 200-4, the ticket checking terminal 200-5, and the ticket checking terminal 200-6 determine whether the identifier 300-1 is absent from the respective data list, and if the identifier 300-1 is absent, send a data acquisition request carrying the identifier 300-1 to the local server 100, and the local server 100 provides the first ticketing data marked by the identifier 300-1 to the corresponding ticket checking terminal according to the data acquisition request. .

It should be noted that the propagation manner of each node propagating the second ticket data in the peer-to-peer network is the same as the propagation manner of propagating the first ticket data, and details are not repeated here.

In one embodiment, in order to enable each ticket checking terminal 200 to check the ticket checking data directly according to the first ticket data in the ticket checking without combining with the second ticket data of its own, each node in the peer-to-peer network may be further configured to update the first ticket data stored in itself according to the second ticket data of its own. The updating mode may include: the ticket checking terminal 200 may search for the first ticket data corresponding to the second ticket data through the ticket number, and add the checked identifier to the first ticket data, or further add other related information (e.g., information such as a ticket checking port and a ticket checking time) included in the second ticket data, so as to update the first ticket data. Therefore, the condition that a plurality of illegal users respectively hold the same legal ticket to enter at different moments can be avoided.

In one embodiment, the local server 100 may be further configured to upload the second ticketing data obtained from the ticket checking terminal 200 to the ticketing data center for the ticketing data center to update the first ticketing data according to the second ticketing data, so that the ticketing data center can also update the first ticketing data in the ticket checking synchronously.

For example, the local server 100 may upload the second ticketing data to the ticketing data center 300 after receiving the second ticketing data. The ticketing data center 300 updates the latest first ticketing data stored therein according to the second ticketing data. This allows the user to view the entire ticket experience through the ticketing data center 300. It should be noted that, the manner in which the ticketing data center 300 updates the first ticketing data may refer to an updating manner in which each node in the peer-to-peer network updates the first ticketing data stored in itself according to the respectively obtained second ticketing data.

In one embodiment, in order to improve the real-time performance of each node in the peer-to-peer network for propagating the ticket data of each node, so as to further ensure the accuracy of ticket checking, a specific way of each node propagating the ticket data of each node in the peer-to-peer network may be: and each node propagates the ticket data in the peer-to-peer network according to the set triggering event.

The above trigger event may include any one or more of: acquiring new ticket data, changing other nodes which can be connected, and adding a new node into the peer-to-peer network.

For the triggering event for acquiring the new ticketing data, after each node acquires the new ticketing data, the new ticketing data is transmitted in the peer-to-peer network, so that other nodes can acquire the new ticketing data in time, and the ticket checking accuracy of the field ticket checking system is further improved.

For the other two triggering events, when other nodes connected to each node are changed (for example, a node connected to one node is failed), or when a new ticket verifying terminal 200 is configured as a node of the peer-to-peer network involved in the present embodiment, that is, when a new node joins the peer-to-peer network involved in the present embodiment, this may cause the connection between nodes of the entire peer-to-peer network to be changed, in order to ensure that other nodes connected to each node can receive the ticket data owned by each node itself, so as to further improve the ticket verifying accuracy of the field ticket verification, when other nodes connected to each node are changed, or when a new node joins the peer-to-peer network, each node retransmits the ticket data owned by each node in the peer-to-peer network.

In order to meet the personalized requirements of users, the field ticket checking system provided by one embodiment of the invention can support the modification of the triggering event. In this embodiment, each node may provide a first set entry that sets the trigger event; acquiring a trigger event input through a set entry; and updating the set trigger event as an input trigger event.

In one embodiment, the local server 100 in the ticket checking system shown in fig. 4 may be further configured as a ticket checking terminal 200, so that the local server 100 may also obtain the ticket checking data through scanning and the like, and check the obtained ticket checking data according to the first ticket data to generate the second ticket data, and simultaneously propagate the second ticket data generated by itself in the peer-to-peer network. Based on the mode, the number of the ticket checking terminals 200 can be increased, so that the ticket checking speed of field ticket checking is improved.

The on-site ticket checking system provided by the embodiment of the invention configures the local server and the ticket checking terminals included in the on-site ticket checking system as nodes in a peer-to-peer network, so that no central node exists in the local server and the ticket checking terminals. Meanwhile, ticket data of each node in the peer-to-peer network is propagated in the peer-to-peer network, and ticket checking operation can be completed. Here, because the ticket checking system provided in this embodiment can perform data synchronization between nodes without setting a central node, and further accurately complete a ticket checking operation, even if some nodes in the peer-to-peer network temporarily fail, other nodes can still perform data synchronization without affecting the normal operation of the ticket checking system, and therefore, the ticket checking system of the embodiment of the present invention can improve the fault resistance. On the other hand, the ticket checking system provided by the embodiment of the invention does not need to erect AP equipment, so that the complexity and the construction cost of the ticket checking system are reduced.

< example >

In this example, in the ticket checking system shown in fig. 4, each ticket checking terminal 200 and the local server 100 are provided with an adhoc module, and each ticket checking terminal 200 and the local server 100 are set to become nodes in an adhoc network. In the adhoc network, the adhoc module is used for synchronizing the first ticket data and the second ticket data generated in ticket checking so as to ensure the final consistency of the ticket data of each node, thereby allowing the adhoc network to have second-level recovery time caused by networking and failure.

For the ticketing system shown in fig. 4, the establishment of an ad hoc network may include the following steps:

step A, initializing networking, wherein the initializing networking can be divided into the following two stages:

step A1, the stage of spreading the inquiry message: after the nodes are started, a topology discovery request message REQ is broadcasted, the topology discovery request message REQ comprises the unique mark number of the node, after other nodes receive the topology discovery request message REQ sent by the node, mark information of each node and topology information of other nodes collected by each node are added to the topology discovery request message REQ, the topology discovery request message REQ is broadcasted, and meanwhile, local adjacent node information of each node is created. When the broadcast topology request phase is over, each reachable node in the network constitutes an ad hoc network.

Step A2, topology information timing synchronization: the node synchronizes the network topology information with the adjacent nodes which can be connected.

Step B, node joining and node leaving processes: when a new node is added, the stage of spreading the query message is executed according to the step A1, and the network topology is obtained, namely, the new node is added into the adhoc network. When a node fails, the node belongs to topology information change, and when the node fails, equipment leaves the network at any time, only the local network is temporarily influenced, and the whole network cannot be influenced. And when the local network fails, the network topology information is timed and synchronized according to the step A2, and the capability of quick recovery is provided.

And step C, each node adopts a self-contained dynamic routing protocol to carry out data synchronization based on the routing function of the adhoc module, and the data synchronization comprises the synchronization of the first ticket data and the second ticket data of each node.

The present invention may be a computer program product designed according to the functions of the local server 100 and the ticket checking terminal 200, respectively. The computer program product may include a computer-readable storage medium having computer-readable program instructions embodied therewith for causing a processor to implement various aspects of the present invention.

The computer readable storage medium may be a tangible device that can hold and store the instructions for use by the instruction execution device. The computer readable storage medium may be, for example, but not limited to, an electronic memory device, a magnetic memory device, an optical memory device, an electromagnetic memory device, a semiconductor memory device, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of the computer-readable storage medium include a portable computer diskette, a hard disk, a random access memory (RAM, a read-only memory (ROM, an erasable programmable read-only memory (EPROM or flash memory), a static random access memory (SRAM, a portable compact disc read-only memory (CD-ROM), a digital versatile disc (DVD, a memory stick, a floppy disk, a mechanical coding device, a punch card or an in-groove protrusion structure having instructions stored thereon, for example, and any suitable combination of the foregoing.

The computer-readable program instructions described herein may be downloaded from a computer-readable storage medium to a respective computing/processing device, or to an external computer or external storage device via a network, such as the internet, a local area network, a wide area network, and/or a wireless network. The network may include copper transmission cables, fiber optic transmission, wireless transmission, routers, firewalls, switches, gateway computers and/or edge servers. The network adapter card or network interface in each computing/processing device receives computer-readable program instructions from the network and forwards the computer-readable program instructions for storage in a computer-readable storage medium in the respective computing/processing device.

The computer program instructions for carrying out operations of the present invention may be assembler instructions, instruction set architecture (ISA instructions, machine-related instructions, microcode, firmware instructions, state setting data, or source or object code written in any combination of one or more programming languages, including an object oriented programming language such as Smalltalk, C + + or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages In some embodiments, the various aspects of the present invention are implemented by personalizing electronic circuitry, such as programmable logic circuits, field programmable gate arrays (FPGAs, or Programmable Logic Arrays (PLAs), that execute computer-readable program instructions, with state information of the computer-readable program instructions.

It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer readable program instructions.

These computer-readable program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks. These computer-readable program instructions may also be stored in a computer-readable storage medium that can direct a computer, programmable data processing apparatus, and/or other devices to function in a particular manner, such that the computer-readable medium storing the instructions comprises an article of manufacture including instructions which implement the function/act specified in the flowchart and/or block diagram block or blocks.

The computer readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer implemented process such that the instructions which execute on the computer, other programmable apparatus or other devices implement the functions/acts specified in the flowchart and/or block diagram block or blocks.

The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of instructions, which comprises one or more executable instructions for implementing the specified logical function(s). In some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions. It is well known to those skilled in the art that implementation by hardware, by software, and by a combination of software and hardware are equivalent.

Having described embodiments of the present invention, the foregoing description is intended to be exemplary, not exhaustive, and not limited to the embodiments disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is chosen in order to best explain the principles of the embodiments, the practical application, or improvements made to the technology in the marketplace, or to enable others of ordinary skill in the art to understand the embodiments disclosed herein. The scope of the invention is defined by the appended claims.

Claims

1. A field ticket checking system comprises a local server and a plurality of ticket checking terminals; each ticket checking terminal and the local server are configured to be nodes in a peer-to-peer network, and each node is connected with at least one other node; the local server is configured to connect to a ticketing data center via a wide area network;

2. A system according to claim 1, wherein the local server is further arranged to upload the second ticketing data obtained from the ticketing terminal to the ticketing data center for the ticketing data center to update the first ticketing data in accordance with the second ticketing data.

3. A system according to claim 1, wherein each node is further arranged to update the first ticket data stored in itself in dependence on the second ticket data obtained in each case.

4. The system of claim 1, wherein the local server is configured to: and acquiring the first ticket data from the ticket data center in response to a set acquisition event.

5. The system of claim 4, wherein the set acquisition event comprises any one or more of: when the set time interval is up, newly establishing communication connection with the ticket data center, and receiving an update notification sent by the ticket data center according to the update of the first ticket data.

6. The method of claim 4, the local server further configured to:

providing a first setting entrance for setting the acquisition event;

acquiring an acquisition event input through the first setting entrance;

and updating the set acquisition event as the input trigger event.

7. The system of claim 1, wherein said each of said nodes propagates respective ticketing data throughout said peer-to-peer network, including:

and each node sends the ticket data which each node has to the target node.

8. The system of claim 1, each of the first ticketing data and each of the second ticketing data has a unique data identification; the nodes propagate the ticket data in the peer-to-peer network, including:

9. The system of claim 1, wherein said each of said nodes propagates respective ticketing data throughout said peer-to-peer network, including:

wherein the trigger event comprises any one or more of: acquiring new ticket data, changing other nodes capable of being connected, and detecting that a new node joins the peer-to-peer network.

10. The method of claim 9, each of the nodes configured to:

providing a second setting entry for setting the triggering event;

acquiring a trigger event input through the second setting entrance;

and updating the set trigger event to be the input trigger event.

11. The system according to claim 1, wherein the ticket checking terminals are further configured to check the obtained ticket checking data according to the first ticket data of the respective ticket checking terminals to generate a check result, and prompt the check result.

12. The system of claim 1, wherein the second ticketing data includes any one or a combination of: ticket number, ticket checking time, ticket checking terminal identification, check-in identification/check-out identification.

13. A system according to any one of claims 1 to 12, wherein the peer-to-peer network is an ad hoc network, each of the nodes being provided with an ad hoc module.