Server Polling Code for Reliable Transaction Status Updates
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing systems for providing transaction status information between a client and a server are unreliable due to the interruption of network connections, which leads to loss or delay of status updates, especially for time-consuming transactions like credit card verification, as they rely on persistent connections that are difficult to maintain.
Innovation Solution
A method and system that generates polling code with a Uniform Resource Locator (URL) including parameters like delay time and polling count, allowing the client to periodically check the transaction status with the server without a persistent connection, using a server agent and client code generator to manage the polling process and redirect the user accordingly.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If a persistent network connection is used to provide transaction status information, then the server can communicate status updates to the client, but the connection is easily interrupted by network traffic or service provider errors causing loss or delay of status information
Solution Approach 1:
The system implements periodic polling where the client sends status requests to the server at regular intervals. The server processes these requests and returns status information without requiring a persistent connection. This periodic action mechanism ensures reliable status delivery while being resilient to network interruptions, as each poll is an independent request-response cycle.
Solution Approach 2:
The patent introduces a polling mechanism as an intermediary between the client and server. Instead of relying on a persistent connection to carry status information, the polling process acts as a mediator that periodically carries status updates from the server to the client. This intermediary approach isolates the status delivery from direct dependency on connection persistence.
2Reliability
If the client continuously monitors transaction status by polling the server, then status information is reliably obtained, but network traffic increases and connection persistence becomes more difficult
Solution Approach 1:
The system uses periodic polling with configurable intervals to monitor transaction status. This approach provides reliable status information availability while avoiding the complexity of maintaining persistent connections. The polling frequency can be adjusted based on transaction characteristics, balancing information availability with network resource consumption.
Solution Approach 2:
The client autonomously implements the polling mechanism to check transaction status without requiring server-initiated communication or persistent connection maintenance. The client self-manages the monitoring process by periodically sending requests and processing responses, eliminating the need for complex connection persistence mechanisms.
3Adaptability or versatility
If the server processes transactions that require external resource interaction, then comprehensive transaction functionality is achieved, but processing time increases causing status information to be delayed or lost
Solution Approach 1:
The system implements periodic status polling that works effectively with long-running transactions that require external resource interaction. Instead of requiring real-time status updates through persistent connections, the periodic polling mechanism checks for transaction completion at intervals, accommodating the time needed for external resource interactions while maintaining status information availability.
Solution Approach 2:
The polling mechanism maintains continuous monitoring of transaction status throughout the entire processing time, including periods when external resources are being accessed. This continuous action ensures that status information is eventually obtained regardless of how long the transaction takes to complete, without interrupting the external resource interaction process.
Data Source
AI summary
Under the present invention, polling code is generated on a server and sent to a client in response to a transaction request received on the server from the client. The polling code includes a set of parameters such as a delay time and a polling count. After expiration of the delay time, the client will poll the server to request the status of the requested transaction. If the transaction is complete, the client will be redirected to a completion page. If the transaction is incomplete, and a polling count limit has not been reached, new polling code will be generated that includes the delay time and a new polling count. The new polling count is generated by incrementing the old polling count by one. The polling cycle is repeated until the transaction is complete, or the polling count limit is reached.