Cloud printing with queue message service

Abstract

The present disclosure describes a Queue Message Service (QMS) that is a multi-zone, low-latency and reliable service for managing a large number of persistent message queues to achieve asynchronous target communications. The universal internal service QMS can be used for printing queues and can also be used for command queues of sensors. One example implementation of a QMS is a print service. According to the implementation, status indicators are introduced into the printer, and the status indicators can identify whether the printer is in a blocked state, an off-line state, a suspected fault state, a normal operation state and the like.

Description

Technical Field

[0001] This application claims priority to the filing date of U.S. Provisional Application No. 63 / 393,090, filed on July 28, 2022, the disclosure of which is hereby incorporated by reference herein. Background Art

[0002] Cloud printing services must provide reliable and fast batch ticket printing. Pull-based printers, while reliable, are not suitable for fast printing. In pull-based printing, each request arrives at a different server node at a set frequency (for example, every 5 seconds). In addition, when responding to requests, the database is queried, resulting in a high input / output (I / O) load. This setting does not scale well, and the I / O load and connection overhead make it impossible to achieve faster printing simply by increasing the frequency. At the same time, it is also difficult to determine whether a pull-based printer is offline or only temporarily connected. Printers usually have some abnormal and failed tasks, which should affect the assessment of the overall status of the printer, but in actual operation, the printer may not be able to print all tasks but still think it is in a normal state. Summary of the invention

[0003] In contrast, push-based printers are permanently connected through an intermediary Message Queuing Telemetry Transport (MQTT) broker, but are less reliable due to poor control over printer anomalies and network issues. Existing cloud printing services effectively offload error handling to printers, but with mixed results. Some printers cannot handle more than one task at a time without erroring out, but it is difficult for servers to guarantee this while maintaining fast printing. In particular, the service cannot distinguish between a slow printer and a lost job message, so it cannot determine whether a print job needs to be resent.

[0004] The present invention describes a queue message service (QMS) that provides a multi-region, low-latency and reliable service for managing a large number of persistent message queues to achieve asynchronous target communication. This general internal service QMS can be implemented in print queues as well as sensor command queues.

[0005] An example implementation of the QMS described in this article is a print service that uses the memory exclusivity semantics of QMS to implement graceful reconnection, as it can quickly detect and close previous connections that appear to be active but are actually stale. It also uses the lease state to detect if a predetermined time threshold has passed since the printer last connected / queried for a task. This implementation also introduces status indicators inside the printer, where these status indicators can determine whether the printer is blocked, offline, suspected to be faulty, normal, etc. All print attempts and the reasons for success / failure are logged. The service logic can be used to calculate the state and use it as a basis for further actions. For example, tasks will not be sent to blocked printers, providing more reliable printing, as some printers will silently discard received tasks in this state. The print service marks a printer as "suspected faulty" when it cannot print a task for any reason, which helps identify faulty printers. This also helps identify configuration problems, such as incorrect formatting, in which case the printer itself claims that it is normal, but something else went wrong. Otherwise, such problems are difficult to detect.

[0006] One aspect of the present disclosure provides a system comprising a memory and one or more processors in communication with the memory. The one or more processors may be configured to: allocate an address range of a database to each of a plurality of coordinators by a leader, wherein each coordinator manages communications with a subset of one or more peripheral devices connected to the system; receive an incoming message by a writer; enqueue the message in a database by the writer; and notify one of the plurality of coordinators having an address range containing the address of the enqueued message by the writer based on the address of the enqueued message.

[0007] In some embodiments, the one or more processors may also be configured to: transmit the queued message by the reader to a recipient. The recipient may be, for example, a peripheral device. For example, the peripheral device may include at least one of a speaker, a display, or a printer.

[0008] In some embodiments, the reader may be configured to: load a payload of the enqueued message from a database; and send an acknowledgement reply to one of the plurality of coordinators having an address range that includes the address of the enqueued message.

[0009] In some embodiments, the plurality of coordinators may be configured to maintain a state for each of the plurality of connected peripheral devices.

[0010] In some embodiments, the leader may also be configured to distribute the load among multiple coordinators.

[0011] In some embodiments, multiple coordinators may maintain metadata of queue messages and the delivery progress of messages.

[0012] In some embodiments, the memory may store a shard allocation table indicating a correlation between each of the plurality of coordinators and an allocated address range.

[0013] In some embodiments, each of the plurality of coordinators may be configured to scan queues within an assigned address range in the database to check for newly submitted messages.

[0014] Another aspect of the present disclosure provides a method, the method comprising: connecting a receiving device to a reader of a queue message service (QMS) node; receiving a message sent to the receiving device at a writer of the QMS node; writing the payload of the message to a database by the writer of the QMS node; notifying a coordinator of the QMS node by the writer that the message has been written to the database; and based on the state of the receiving device, instructing the reader by the coordinator to pass the message from the database to the receiving device. 12. According to some examples, the receiving device may be a printer and the message may be a print job. The method may also include sending a confirmation reply by the reader to the coordinator.

[0015] In some examples, the method may also include: determining, by the coordinator, a state of the receiving device according to a heartbeat signal of the receiving device; and maintaining, by the coordinator, the state of the receiving device.

[0016] In some examples, the method may also include: maintaining, by the coordinator, metadata of the queue message and a delivery progress of the message.

[0017] In some examples, the method may also include storing a shard allocation table indicating a correlation between the coordinator and the allocated address ranges in the database.

[0018] In some examples, the method may further include: scanning, by the coordinator, queues within an allocated address range in the database to check for newly submitted messages.

[0019] Another aspect of the present disclosure provides a non-volatile computer-readable medium storing instructions executable by one or more processors to perform a method. The method includes: connecting a receiving device to a reader of a queue message service (QMS) node; receiving a message sent to the receiving device at a writer of the QMS node; writing the payload of the message to a database by the writer of the QMS node; notifying the coordinator of the QMS node by the writer that the message has been written to the database; and based on the state of the receiving device, instructing the reader by the coordinator to pass the message from the database to the receiving device. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] Figure 1 is a block diagram of a simplified example architecture of a QMS (Queue Message Service) shown in accordance with aspects of the present disclosure.

[0021] Figure 2 is a block diagram of another example architecture of a QMS shown according to aspects of the present disclosure.

[0022] Figure 3 is a block diagram of an example computing device of a QMS illustrated according to aspects of the present disclosure.

[0023] Figure 4 It is a block diagram of an example implementation process of QMS in cloud printing according to aspects of the present disclosure.

[0024] Figure 5 It is a block diagram of another example implementation process of QMS in cloud printing according to aspects of the present disclosure.

[0025] Figure 6 is a block diagram of an exemplary keyed event queue architecture.

[0026] Figure 7 is a functional block diagram of an example implementation of QMS in cloud printing according to aspects of the present disclosure.

[0027] Figure 8 is a flow chart of an exemplary method that may be implemented according to aspects of the present disclosure. DETAILED DESCRIPTION

[0028] The present disclosure provides a queue message service (QMS) that supports multi-region, low-latency and reliable communication. An example implementation of the QMS is a cloud printing service.

[0029] Example system:

[0030] Figure 1 A simplified block diagram is provided that shows the architecture of an example messaging system. Each message receiver has a permanent "address" to which any sender can queue messages. Once a message is accepted by the broker, it is delivered to the receiver at least once in order. The message broker is configured to handle multi-region communication in addition to handling asynchronous exclusivity and volatility. Regarding asynchrony, the receiver is not always connected. Messages are accepted even when the receiver is not connected and are delivered as soon as the receiver connects. Regarding exclusivity, the receiver may fail and reconnect, and therefore may be briefly connected to multiple machines at the same time. Regarding volatility, the receiver may be briefly connected to different machines at a time just to receive messages. The broker continues to work even in the face of such volatile receivers.

[0031] QMS is a multi-region messaging service that uses a distributed database for message persistence and accounting, and a key-value store for leader election. Each "address" in QMS can be a unique identifier. For example, each address can be a region / universally unique identifier (UUID) pair. For multi-tenancy, addresses exist in disjoint namespaces. Scalability is achieved by splitting the region / UUID space so that no single node needs to manage all addresses.

[0032] Figure 2 An example QMS architecture 200 of a QMS node is shown, including a leader 230, one or more coordinators 220, one or more writers 210, one or more readers 240, and a distributed database 250. The leader 230, the coordinator 220, the writer 210, and the reader 240 can be modules, threads, instructions, or the like stored in memory and executed by one or more processors. The QMS node can be used to pass messages between a sender and a receiver. At any given time, multiple senders and receivers can communicate using the QMS node. By way of example only, a sender may be a server that generates messages for multiple receiver devices located at different remote locations. For example, a receiver device may include a printer, display, speaker, or other type of peripheral device located at different locations.

[0033] The leader 230 may be dynamically selected from the nodes. For example, the leader 230 may be selected based on availability, rotation, randomness, self-nomination confirmed by the node, or any other leader election method. The leader 230 may be responsible for shard allocation and load distribution among all coordinators. The leader 230 may also be responsible for publishing a shard allocation table to facilitate direct communication between nodes and coordinators. For example, the shard allocation table may publish information for establishing a multiplexed bidirectional stream connection, such as using remote procedure calls (RPC), gRPC, HTTP, etc. This information may include the address, routing, or other connection information of a particular coordinator 220.

[0034] The coordinator 220 can communicate with the leader 230 through heartbeats to renew the leader's ownership lease. If the leader crashes, the new leader will take over and collect the existing task allocations in the coordinator. If one of the coordinators 222, 224 crashes, the leader 230 will reallocate the shards after its lease expires.

[0035] Each coordinator 222, 224 is responsible for one shard. Shards can be defined per region, and each shard may contain a series of addresses, such as UUIDs. Each receiver can connect to the specific coordinator responsible for its address through a worker (not shown). In some cases, a receiver can sub-lease ownership of a single address from the coordinator. Similarly, if the receiver wants to disconnect gracefully, it can also relinquish the address. This sub-lease semantics can guarantee exclusivity to the receiver. Each writer 212, 214, 216 can also communicate with each coordinator 222, 224.

[0036] Each coordinator 222, 224 maintains queue message metadata and delivery progress in memory, and is persistently supported by regionalized database tables. Database tables may include, for example, message tables, queue tables, cursor tables, etc. For example, messages may be stored in a table indexed by (region, domain, key, sequence number) with corresponding payloads. Queues may be stored in a table indexed by (region, domain, key) with corresponding sequence numbers. Queue tables may serve as indices of messages that may actually be scanned. Cursors may be stored in a table indexed by (region, domain, key) with corresponding processing sequence numbers.

[0037] The payload of the message is not sent through the coordinator 220. The coordinators 222, 224 receive notifications of new messages directly, but also periodically scan the queue table in case a new message is submitted but no notification is sent, thus ensuring that no message delivery is missed. Each delivered message requires an explicit acknowledgement of receipt by the recipient to confirm delivery before the next message is sent. Once a delivered message is acknowledged, the coordinator 222, 224 can move the cursor.

[0038] The coordinator 222, 224 naturally knows the connection status of the recipient, the last connection time, etc. Based on this connection status, the coordinator 222, 224 can display whether the recipient is "online" or "offline", as well as the message backlog, administrative operations of queue operations, etc.

[0039] In this example, the coordinator 222, 224 has full control over address ownership and delivery semantics. This provides flexibility to accommodate a variety of message queue service (QMS) use cases. For example, the coordinator can choose how to assign winners of address requests. In some cases, the last connected receiver wins, but other approaches are possible. In some cases, multiple receivers can have the same address and use a variety of delivery strategies, such as polling, random, multicast, assigning a time to live to messages, etc.

[0040] Writer 210 is responsible for enqueuing incoming messages. For example, when writer 212, 214, 216 receives an incoming message, it assigns the next sequence number to the message and commits, and if the commit succeeds, asynchronously sends a notification to the corresponding coordinator responsible for the shard containing the message address. After committing, the writer sends a notification to the coordinator that owns its enqueued message. For example, a shard allocation table can be used to determine which coordinator to notify, and the determination is based on the address of the enqueued message. For example, a message with a key of (region1,b) may be owned by an allocation in the range of (region1,[ad]). The shard allocation table contains information, such as the IP address and identifier of the coordinator, indicating how to connect the writer to the coordinator. Writers can enqueue messages from any region. Because database transactions are used, concurrent writes can be serialized. If the commit succeeds, the message is accepted. If the coordinator is unreachable or down, or the node crashes after the commit, the coordinator's periodic scan will eventually find and deliver the message.

[0041] Readers 242, 244, 246 may be responsible for delivering messages to locally connected recipients. Recipients may include, for example, computing devices or peripherals such as printers, displays, speakers, etc. According to some examples, a given recipient may have a corresponding reader 242, 244, 246 so that the recipient uses the given reader to retrieve the message. For example, a first computing device may correspond to reader 242, and a second computing device may correspond to reader 244. The first and second computing devices may have the same or different device types, protocols, regions, etc.

[0042] When a receiver connects, the reader 242, 244, 246 will try to get the address from the corresponding coordinator 222, 224, which will then push the next message for delivery when it is available. If the address is already occupied, the coordinator will try to revoke the old occupation and assign it to the new receiver after it is released. The old receiver will then be disconnected.

[0043] The payload of the message is loaded by the reader from the database 250. Acknowledgements are forwarded to the coordinators 222, 224. If a receiver loses possession of the address, it will be disconnected. If a reader 242, 244, 246 crashes, it will lose its sub-lease as it cannot renew it. For convenience, readers allow multiplexing of receivers on the same connection established with the coordinator.

[0044] According to some examples, the system may include multiple QMS nodes, each of which has the above-described architecture 200. The system can be expanded by creating additional instances. The QMS can also provide transactional enqueues so that a service can submit one or more QMS and key event queue (KEQ) messages and the status of the service in a database transaction.

[0045] Although the above example illustrates a specific number of writers, readers, coordinators, and other components, it should be understood that this is only one example. Other examples may include different numbers of each type of component. Furthermore, the number of each component does not necessarily correspond to the number of other components. For example, a system may include more writers than readers, more readers than writers, etc.

[0046] Figure 3 An example computing device 300 is shown that can be configured to perform the QMS process described above. The computing device 300 includes one or more processors 320, a memory 330, and other components typically found in a computing device. The memory 330 can store information accessible by the one or more processors 320, including instructions 334 that can be executed by the one or more processors 320.

[0047] The memory 330 may also include data 332 that may be retrieved, manipulated, or stored by the processor. The memory may be of any non-transitory type capable of storing information accessible by the processor, such as a hard disk, a memory card, a read-only memory (ROM), a random access memory (RAM), a digital video disk (DVD), a compact disk-read-only memory (CD-ROM), a writable memory, and a read-only memory.

[0048] Instructions 334 may be any set of instructions to be executed directly (e.g., machine code) or indirectly (e.g., scripts) by one or more processors. In this regard, the terms "instructions," "application," "steps," and "program" may be used interchangeably herein. Instructions may be stored in an object code format for direct processing by a processor, or in any other computing device language, including a collection of scripts or independent source code modules that are interpreted on demand or compiled in advance. The functions, methods, and routines of the instructions will be described in more detail below.

[0049] Data 332 may be retrieved, stored, or modified by one or more processors 320 in accordance with instructions 334. For example, although the subject matter described herein is not limited to any particular data structure, the data may be stored in a computer register, as a relational database with tables having many different fields and records, or as an extensible markup language (XML) document. The data may also be formatted in any computing device readable format, such as, but not limited to, binary values, ASCII, or Unicode. In addition, the data may include any information sufficient to identify the relevant information, such as numbers, descriptive text, proprietary codes, pointers, references to data stored in other storage (e.g., other network locations), or information used by a function to calculate the relevant data.

[0050] The one or more processors 320 may be any conventional processor, such as a commercially available central processing unit (CPU). In addition, the processor may be a dedicated component, such as an application specific integrated circuit (ASIC) or other hardware-based processor. Although not required, one or more of the computing devices 300 may include dedicated hardware components for performing specific computing processes.

[0051] The computing device 300 may include a communication interface 340 that enables the device 300 to communicate with other components (e.g., a distributed database, a key-value store, a consumer system, etc.). The computing device may communicate with other devices over a network and using various protocols and systems, such that the network may be part of the Internet, the World Wide Web, a specific intranet, a wide area network, or a local area network. The network may utilize standard communication protocols, such as Ethernet, WiFi, Hypertext Transfer Protocol (HTTP), protocols described in IEEE 302.33, cellular technologies (e.g., Global System for Mobile Communications (GSM), Code Division Multiple Access (CDMA), Universal Mobile Telecommunications System (UMTS), Evolution Data Optimized (EV-DO), Worldwide Interoperability for Microwave Access (WiMAX), Long Term Evolution (LTE), etc.), proprietary protocols of one or more companies, and various combinations of the above. Although certain advantages are obtained when information is transmitted or received in the manner described above, other aspects of the subject matter described herein are not limited to any particular manner of information transmission.

[0052] although Figure 3 The processor, memory, and other elements are functionally shown as being located in the same module, but in fact, the processor, computer, computing device, or memory may include multiple processors, computers, computing devices, or memories, which may or may not be located in the same physical housing. Therefore, references to processors, computers, computing devices, or memories will be understood to include references to a collection of processors, computers, computing devices, or memories that may or may not run in parallel. In addition, although some of the functions described below are indicated as being performed on a single computing device with a single processor, various aspects of the subject matter described herein may be implemented by multiple computing devices, for example, in the cloud. Similarly, memory components located in different locations may store different parts of instructions 334 and together constitute a medium for storing instructions. Various operations described herein as being performed by a computing device may be performed by a virtual machine. For example, instructions 334 may be specific to a first type of server, but related operations may be performed by a second type of server running a hypervisor that simulates the first type of server. Operations may also be performed by containers, for example, a computing environment that does not rely on an operating system associated with a particular type of hardware.

[0054] An example implementation of a QMS (queue management system) is a cloud printing service, in which a print task is sent from a first computing device located at a first location to a printer located at a second location remote from the first location. Such a cloud printing service may use a QMS to represent a queue of print tasks, where each message is a print task. The payload of the message may include, for example, a print file or format, graphics, text, or other types of print information. The QMS can also serve as a notification mechanism for new print tasks for long-polled printers. The cloud printing service can use the QMS by converting a job queue name into a zone / UUID address for submitting and retrieving print tasks. According to some examples, the print operation can be used to enqueue a message so that some additional state can be maintained in a transactional manner.

[0055] The Cloud Print protocol can use different calls to process print tasks. Example calls might include POST, GET, and DELETE. The Cloud Print service can record any in-progress jobs in its own table so that it can send an acknowledgment to the QMS when a GET call is issued. In other examples, the Cloud Print service can wait for the printer to call DELETE. The Cloud Print service can relinquish the QMS sublease after each acknowledgment to ensure that it can be reacquired immediately after the next DELETE. The Cloud Print service avoids internal communication by maintaining a single print task in-progress buffer. Printer authentication can also be handled by the Cloud Print service.

[0056] The example cloud print service described in this article can handle both push-based protocols (such as MQTT) and poll-based protocols. For reliability, printer observability and garbage collection can be isolated in separate processes so that if the observability dependency fails, it does not affect the import-to-print process. The code that performs printing can be isolated from the code that reports on how well the print job is doing and deletes old tasks. In this regard, if the latter code is not working or is slow, printing is still fast. The time from receiving a print job to printing a ticket for it can still be fast.

[0057] Figure 4 An example low-latency printing process is shown according to aspects of the present disclosure. The process occurs between components including one or more writers 412, 414, one or more readers 442, 444, a QMS print queue 460, and a distributed database 450. The printing process includes operations on the writer side and the reader side, where these operations meet at the QMS print queue.

[0058] On the printer side of the process, the printer connects to the reader via, for example, MQTT. The reader makes a request to the QMS. The printer periodically sends a heartbeat to the QMS via the reader to maintain the request. The QMS maintains a cursor of processed messages, for that printer. If all are caught up, no action is taken. It also records in memory that the printer is online.

[0059] On the writer side, the print job is received at the system, the service generates a print ticket and queues the print job message to the print job queue in the writer. The writer writes the print job message to the database. If successful, the writer sends a notification to the QMS, telling it that a new print job message has been queued for the printer. The writer then returns an acknowledgment to the system that received the print job, indicating that the print job has been accepted.

[0060] According to the QMS process, the QMS receives notification of a print task message. It knows that the printer is connected and has not yet processed the print task message. Therefore, the QMS can immediately send a message to the reader to deliver the print task message. The reader reads the payload of the print task message from the database and sends it to the printer. The receiver processes the message, such as printing a ticket, and sends a confirmation to the QMS through the reader. The QMS coordinator advances the cursor of the printer by 1. Then, it checks whether there is a new print task message. If there is, it returns to the beginning of the QMS process. If not, the printer has caught up.

[0061] Writer 412, 414 is responsible for storing the incoming print job into the queue management system (QMS). It can look up the QMS area / universally unique identifier (UUID) through the short print queue ID.

[0062] Readers 442, 444 may be responsible for handling various printing protocols to operate and authenticate connected printers. Supported protocols may include only exemplary CloudPRNT, MQTT, or other protocols. According to some examples, each reader 442, 444 may have protocol-specific code 492-495. For example, because different printers use different encodings and protocols (MQTT / HTTP), adapters can be implemented for each printer.

[0063] The Cloud Print protocol uses separate HTTP requests to periodically discover, read, and confirm print requests. Long polling may include delaying the response to the request so that if a new message is received through the QMS during this period, it can be printed immediately. The response can be delayed, for example, for 10 seconds, 20 seconds, 50 seconds, 100 seconds, or any other duration as long as the printer does not time out.

[0064] MQTT printers use long-running connections that hold QMS announcements. Any message received over QMS can be printed immediately. If the QMS announcement is lost, the connection can be broken and the printer reconnected elsewhere. MQTT printers have limited buffer sizes and can usually only handle one or a few jobs in progress at a time. If the load becomes too great, they will drop jobs - sometimes even silently claiming to have printed successfully. MQTT brokers rarely provide features to help avoid such situations. In contrast, QMS queues and exclusivity semantics enable print services to ensure that at most one job is in progress at any given time.

[0065] For any protocol, the print job in progress can be stored in the database 450 table before sending an acknowledgment to the QMS to prevent duplicate printing due to duplicate delivery caused by the QMS or connection failure. For polling-based scatter protocols (such as the cloud printing protocol CloudPRNT), discovery (POST), acquisition (GET), and confirmation (DELETE) are separate HTTP requests and do not map directly to QMS operations. In this regard, the head of the print queue can be buffered so that it is ready for a GET operation after a successful discovery. When the printer confirms, the job in progress will be deleted. The next discovery call will obtain and buffer the next job from the QMS, and the cycle will repeat.

[0066] Each instance contains both components and is scalable because the printing process does not require internal communication.

[0067] Figure 5 An example printer observability flow is shown, including a leader 530 , one or more monitors 570 , a QMS print queue 560 , and a keyed event queue (KEQ) 580 .

[0068] A dynamically elected global leader 530 is responsible for monitoring shard allocation and achieving load balancing among workers.

[0069] Each monitor 570 is responsible for ensuring that the status of all print queues in the shard it is responsible for is correctly reflected in the database 550. It maintains the status of the print queues in memory and queries the QMS's memory status for print job failure information and the time since the last connection. It scans the database 550 periodically to discover newly added and deleted print queues. If a print queue has not been claimed for a period of time (such as minutes), it may be considered to be offline or faulty. If a printer has been offline for a long time (such as days or months), it may be considered damaged and therefore deleted. If the printer is put back into service, it will be considered a new printer with a new name and region / UUID. The benefit of using QMS claimed status is that it is guaranteed to expire in the event of a fault. If a printer is not connected to the print service, its QMS address will not remain claimed and the print service will mark it as offline. In contrast, for MQTT printers, if standard methods are used, for example, the node where the MQTT connection is terminated can mark the printer as online or offline. However, this approach does not work correctly if the node crashes and the printer does not reconnect, because such logic would cause the printer to appear online without doing anything to take it offline. A standard way to overcome this is to periodically update the connection heartbeat in the database, but this approach is expensive and takes a lot of I / O to maintain a stable state even when there are no print jobs.

[0070] A QMS print queue may go through a life cycle of a series of states, such as CREATED, UPDATED, ONLINE / OFFLINE, OUT-OF-PAPER, etc., which are transactionally sent to the KEQ 580 by writing to the database 550. In addition, when a job is printed, the reader will similarly emit a PRINTED event. This allows the print operation that creates and tracks print jobs to handle the print queue status as an update event, rather than periodically calling the print service application programming interface (API) to obtain queue and job status.

[0071] In some examples, leaders and monitors might be used only for shard observability and garbage collection, so that if a leader or monitor fails, normal printing operations are not impacted.

[0072] KEQ 580 is an example message broker. Although KEQ 580 is described in this example, in other examples, other message brokers, such as Kafka, can also be used. Figure 6 An example system implementing KEQ is shown. The system includes a leader 605 and multiple workers 622, 624, which communicate with consumers.

[0073] The leader 605 may be a global leader dynamically selected by the workers 622, 624. The leader 605 may be a server selected from multiple servers, where the non-leader servers are the workers 622, 624. In some examples, the leader 605 may be a software module that is active at any time on a single machine in the cluster. In some examples, the workers 622, 624 may also be software modules, where one or more workers 622, 624 may be active on the machine or node holding the leader or on separate machines.

[0074] The leader 605 may be responsible for shard assignment and load distribution across all workers 622, 624, and for pushing any global topic / subscription information. For example, the leader 605 and workers 622, 624 may form a "control plane" for coordinating how work should be sharded or distributed. By way of example only, the leader 605 may assign shards for order IDs 0-5000 to worker 622, and shards for order IDs 5001-10000 to worker 624. The leader 605 may use a distributed database 670 to store high-level topic and / or subscription information.

[0075] Workers 622, 624 coordinate with the leader to renew their ownership leases. If the leader 605 crashes, the new leader will take over and collect the existing allocations from the workers 622, 624. If a worker or consumer crashes, the leader will reallocate the shards after their leases expire.

[0076] Each worker 622, 624 coordinates the data plane aspects and is responsible for managing consumer connections as well as managing the lifecycle of topics and subscribed shards assigned by the leader. Figure 6 Two workers 622, 624 are shown in FIG, but any number of workers may be included in the system. Furthermore, the number of workers may be expanded upward or downward.

[0077] Workers 622, 624 may be connected to consumers 652. Consumers 652 may be entities or services that perform operations corresponding to each event. For example, when the event corresponds to a takeout order, consumer 652 may be a restaurant that receives the order and prepares the food, or a driver service that picks up the food from the restaurant and delivers it. According to some examples, each event may be a small step in the overall process of receiving a takeout order and delivering it. For example, each event may be anything that happens to an order, such as "order placed", "ready to print", "ticket printed", "ready to cook", "cooked", "ready to pick up", etc.

[0078] Producers take or report some action, update the order information, and append / send the corresponding event to the order event queue. Consumers again read and acknowledge or respond to events. Consumers of order processing may also be producers. For example, a printing service will react to a "ready to print" event to print out a physical ticket in some kitchen, and the order on that ticket needs to be cooked in that kitchen. After the ticket is printed, the printing service will emit a "ticket printed" event (other services may react to this event). When the chef has made the physical product (part of the order), they will press a button to update the order to the "cooked" state and emit a "cooked" event.

[0079] Each consumer connection used to dequeue messages is managed by a worker pool 632, which may be a set of worker objects. Worker pool 632 may match the life cycle of long-lived bidirectional stream connections, deliver messages in order, perform sub-lease message delivery, and manage heartbeats to consumers. Each message is individually acknowledged and sub-leased. When consumer 652 connects, worker pool 632 is created and leader 605 is notified of its existence. Shard allocation may confirm where consumer 652 is connected to. For load balancing, leader 605 may ask worker 622 to disconnect from consumer 652.

[0080] When a shard is assigned to a specific consumer under a worker-level lease, the worker creates a scope 642, 644, which may be specifically responsible for delivering messages in that shard and recording progress. Scope 642, 644 may be a software component responsible for delivering messages in a shard to a specific connected consumer. When a shard is assigned to a subscribed worker and a consumer is connected, a scope is created to listen for notifications and deliver messages. Scope 642, 644 maintains a cursor, which is the tail of the queue (or the latest position in memory) and what has been successfully processed. Messages and cursors form a series of rows in the database. Messages that are eligible to be delivered are called "activated." Once scope 642, 644 has durably recorded that the previous message has been processed, it activates the next message or batch of messages for the queue.

[0081] Maintaining a cursor at the tail of the queue may involve listening to the distributed key-value store 675 for notifications of what changes have occurred to the topic shards since that point, and performing an initial strong scan of the current state of the topic shards. Scopes 642, 644 deliver new messages as quickly as possible, but also handle slower consumers and subscriptions that fall behind. Internally, scopes 642, 644 use concurrent blocking queues to apply back pressure. According to some examples, scopes 642, 644 may pause processing notifications if fully backed up.

[0082] A monitor 652 may be assigned to each topic. The monitor 652 may be a software component associated with a topic shard. It may be dynamically assigned by the leader 605, but is independent of any connected consumer, and may be assigned to any worker 622, 624. The monitor 652 performs the following actions for each shard: remediate if a message was enqueued but the corresponding notification was not sent; expire and delete queues that exceed the retention period; clean up its own cursor range tracking and deleted queues. For example, a range 642, 644 may learn that a queue has been deleted by sending a notification with a sequence number of -1. The monitor 652 stores a cursor persistently to track the notifications that have been sent.

[0083] Monitor 652 periodically scans a shard of distributed database 670. According to some examples, monitor 652 may use eventual consistency reads to avoid conflicts with updates when scanning. Based on the scan results, monitor 652 can determine the actual situation of which queues are added, updated, or deleted.

[0084] Monitor 652 may also observe notifications from distributed key-value store 675 to avoid duplicate notifications, for example, if another component has already issued a notification.

[0085] The distributed key-value store 675 supports monitoring a single key range as a change log, rather than receiving all notifications. Each range 642, 644 sees only relevant changes. Notifications can be issued by "flash" updates, for example, writing a cursor and then immediately deleting it. According to other examples, an in-memory multi-region semi-reliable broadcast (SRB) service can be implemented to handle the broadcast of notifications.

[0086] Writer 680 is responsible for enqueuing incoming messages. For example, writer 680 commits the message using the next sequence number and, if successful, broadcasts a notification asynchronously through distributed key-value store 675. Because distributed database transactions are used, concurrent writes can be serialized. If the commit succeeds, the message is accepted. If for any reason the notification is not sent, monitor 652 will eventually discover it for delivery.

[0087] Notifier 685 allows external writers to issue distributed key-value store notifications. It can be used by remote topics after transactional enqueueing. Remote topics may differ from internal topics in terms of writing and deleting messages / queues. For example, internal topics are processed through writer 680. In contrast, remote topics can write directly to distributed database 670 and then call notifier 685 to have KEQ deliver the message quickly. KEQ may have read-only access to remote tables. Deletion of messages / queues for remote topics can be performed by external writers instead of monitor 652. Although writer 680 and notifier 685 are shown as separate components, they may be modules within the same computing device.

[0088] In operation, a leader 605 is elected and declares itself the leader. All workers 622, 624 connect to the leader 605. The leader 605 distributes work to all workers 622, 624. The leader 605 tries to distribute the work evenly while taking into account regional affinity as much as possible. The leader 605 may choose to assign some shards of the subscription to the workers 622. When a shard is assigned, the worker 622 creates a scope 642 for that shard. The scope 642 and monitor perform message processing for their assigned shards. The scope 642 begins listening for notifications from the corresponding topic shards that indicate that the queues in the distributed database 670 have changed. The scope 642 then scans the cursor and queue metadata to know exactly how many messages are in the queues in the shards and which messages have been processed by the consumer 652. If it falls behind for any queue, the scope 642 activates the next message. For each new message, the new message is appended by calling the writer 680, which writes the message to the database 670 and updates the metadata. It then sends an opportunistic "fast path" notification to let all affected scopes 642 know that there is a new message available for delivery. When scope 642 sees the notification, it can activate the message immediately if consumer 652 is not behind. Scope 642 reads the message payload from database 670 and sends it to consumer 652. Consumer 652 receives the message and performs necessary actions - sometimes nothing. It then sends an ACK to scope 642 in response to the message. Scope 642 receives the ACK, indicating that the message was processed correctly. It updates the cursor in database 670 to durably record progress. When it is done, it activates the next message in the queue, if there is one.

[0089] Back to Figure 5 , monitor 570 can detect print queue backlogs, delays, and print times. This information can be published as metrics and used for planning, maintenance, system tuning, etc. The sharding architecture enables distributed print services to report real-time metrics such as "how many printers are currently online" or "how many jobs are currently in progress."

[0090] With Cloud Print, all printers are effectively pushed through the Quick Targeted Notification Service (QMS). By delaying the poll response, HTTP printers can be tricked into polling for a slightly longer period of time.

[0091] Figure 7 shows another example of Cloud Print Service leveraging QMS. Each printer has a persistent memory section on the QMS node. When a printer connects, Cloud Print Service claims ownership and receives messages reliably in order. When a printer disconnects, Cloud Print Service relinquishes ownership. QMS dynamically distributes the responsibility of all memory section queues to the individual shards.

[0092] Another example implementation of a QMS is an MQTT broker. An MQTT broker can use a QMS as a command queue for each sensor. An MQTT broker can convert MQTT subscriptions to regions / UUIDs for submitting and retrieving commands, thus leaving the QMS as an implementation detail. For incoming sensor data, the broker can use a KEQ.

[0093] According to some examples, other connected devices can also use QMS. For example, when using QMS to print order tickets in a kitchen away from the place where the order was placed, other connected devices may include barcode / QR code scanners, LEDs, etc. These sensors maintain long-term connections and can directly use QMS sub-leases for exclusivity. Commands can be sent quickly and reliably. Sensor authentication can be handled by the MQTT broker.

[0094] Figure 8 An example method for delivering messages using QMS is shown. The method may be performed by a QMS node. The QMS node may include one or more processors that execute various instructions, threads, etc. Although the method is described below in a particular order, it should be understood that the order of the steps may be modified. In some examples, multiple steps may be performed simultaneously. In addition, steps may be added or omitted.

[0095] In step 810, a receiving device is connected to the reader of the QMS node. The receiving device can be any remote computing or peripheral device, such as a printer, display, speaker, etc.

[0096] In step 820, the writer of the QMS node receives a message from the sender, which is sent to the receiving device. The message may be information to be output by the receiving device, such as a print job to be printed, a message to be displayed, a sound to be output through a speaker, etc. Therefore, the message may include a payload and header information, such as source and destination identifiers.

[0097] In step 830, the payload of the message is written to the distributed database. According to some examples, the coordinators of the QMS nodes can each be assigned a corresponding address range of the distributed database. Each coordinator can also manage the connection of a subset of receiving devices. Therefore, when writing the payload to the distributed database, the writer can write to the address range corresponding to the coordinator or the receiving device.

[0098] In step 840, the writer notifies the coordinator of the QMS node that the message has been written to the distributed database. For example, the writer may notify a specific coordinator that is assigned a message writing address range.

[0099] In step 850, the coordinator determines the state of the receiving device. For example, the receiving device may periodically send a heartbeat signal to the coordinator to provide the coordinator with information about the state of the receiving device. The state may indicate whether the receiving device is connected, online, operating normally, or malfunctioning, etc. The coordinator may store the state and update it each time a new or different state is determined.

[0100] In step 860, the coordinator instructs the reader to pass the message from the distributed database to the receiving device based on the determined state. For example, if the receiving device is connected and ready to receive messages, the coordinator will instruct the message to be sent. However, if the coordinator determines that the receiving device is offline, it may wait for the receiving device to come back online before instructing the message to be sent. In some examples, the coordinator can ping the receiving device to trigger the receiving device to enter a ready mode where it can receive messages.

[0101] The above-described systems and methods enable faster and more reliable message delivery between a server or other computing device and multiple remote recipients. By writing messages to a database, these messages can be retrieved at any time. For example, if a recipient is not connected or fails when a message is sent, the message is not lost, but is stored in the database and can be retrieved once the recipient is connected and resumes normal function.

[0102] Unless otherwise stated, the above alternative examples are not mutually exclusive, but can be implemented in various combinations to obtain unique advantages. Because the above and other features and combinations of variations can be utilized without departing from the scope of the subject matter defined by the claims, the foregoing description of the embodiments should be regarded as illustrative examples rather than limitations on the subject matter defined by the claims. In addition, the examples provided herein and expressions such as "for example", "including", etc., should not be interpreted as limiting the subject matter of the claims to specific examples; on the contrary, these examples are intended to illustrate only one of many possible embodiments. In addition, the same reference numbers in different drawings may represent the same or similar elements.

Claims

1. A system comprising: Memory; as well as One or more processors in communication with the memory, the one or more processors configured to: allocating,by the leader, an address range of the database to each of the,multiple coordinators, where each coordinator manages communications,for one or more subsets of peripheral devices connected to the,system; Receive, where the writer receives the incoming message; Queuing, where the writer queues the message in the database; as well as Notification, by the writer based on the address of the queued message, notifies one of a plurality of coordinators having an address range that includes the address of the queued message.

2. The system according to claim 1, characterized in that The one or more processors are further configured to: send, by the reader, the queued message to the receiver.

3. The system according to claim 2, characterized in that The recipient is a peripheral device.

4. The system according to claim 3, characterized in that The peripheral device includes at least one of a speaker, a display, or a printer.

5. The system according to claim 2, characterized in that The reader is configured as follows: Load the queued messages from the database; And send an acknowledgment receipt to one of the multiple coordinators having an address range that includes the address of the queued message.

6. The system according to claim 1, characterized in that The plurality of coordinators are configured to maintain a state of each of the plurality of connected peripheral devices.

7. The system according to claim 1, characterized in that The leader is further configured to distribute the load among the multiple coordinators.

8. The system according to claim 1, characterized in that The multiple coordinators maintain queue message metadata and message delivery progress.

9. The system according to claim 1, characterized in that The memory stores a shard allocation table indicating a correlation between each of the plurality of coordinators and an allocated address range.

10. The system according to claim 1, characterized in that Each of the plurality of coordinators is configured to scan queues within an assigned address range in the database to check for newly submitted messages.

11. A method comprising: Connect, which connects the receiving device to the reader of the Queue Message Service (QMS) node; Receiving, receiving messages for receiving devices at the writer of the QMS node; Write, the QMS node's writer writes the message payload into the database; Notification: The writer notifies the coordinator of the QMS node that the message has been written to the database; as well as Instructions, based on the state of the receiving device, the coordinator instructs the reader to send a message from the database to the receiving device.

12. The method according to claim 11, characterized in that The receiving device is a printer and the message is a print job.

13. The method according to claim 11, characterized in that Further including: The reader sends a confirmation receipt to the coordinator.

14. The method according to claim 11, characterized in that Further including: The coordinator determines the status of the receiving device based on the heartbeat from the receiving device; And the state of the receiving device is maintained by the coordinator.

15. The method according to claim 11, characterized in that It further includes maintaining queue message metadata and message delivery progress by the coordinator.

16. The method according to claim 11, characterized in that Further included is storing a shard allocation table indicating correlations between the coordinator and the allocated address ranges in the database.

17. The method according to claim 16, characterized in that Further including: The coordinator scans the queues in the allocated address range in the database to check for newly submitted messages.

18. A non-transitory computer readable medium storing instructions executable by one or more processors to perform a method comprising: Connect, which connects the receiving device to the reader of the Queue Message Service (QMS) node; Receiving, receiving messages for receiving devices at the writer of the QMS node; Write, the QMS node's writer writes the message payload into the database; Notification: The writer notifies the coordinator of the QMS node that the message has been written to the database; as well as Instructions, based on the state of the receiving device, the coordinator instructs the reader to send a message from the database to the receiving device.

Images