I created a web service and a mobile application that communicate between each other. When everything is working, it works great. When the server doesn't respond, it starts to break down.
The mobile device sends a message to the server with a bunch of records. Getting the records on the server never seems to be a problem. It gets the records and then sends a response back to the mobile device that the update was received. The PROBLEM is that the mobile device doesn't always get the response, so it doesn't know it shouldn't send those records again for updating.
Next time it sends the records again and now I have duplicate records. How can I solve this?
Idea 1) Create a transaction number unique on the mobile device that I can compare against the server to see if the record was already uploaded. Then just don't write that record and attempt to send back the response that it was written.
Idea 2) Send the records to the server, but before writing them respond to the mobile device that they were received. This way the mobile device can tag them and then send another response to the server telling it to write them. At the point the mobile device almost doesn't care if it gets a response. Only thing, you don't know if the server ever got the message.
Looking for ideas on how to handle this that either confirm one of these ideas or has a completely different one.
I ended up creating logs that the device attempts to resolve when it gets back successful responses from the server.
I tag items as a batch of lines and send them up to the server. Once they are up there, I create a log about the success or failure of each line item in a batch of items and then save the log to the file system.
When the mobile device is unsuccessful in hearing back a response from the server, in rare cases, it asks the server about a batch number. If the server doesn't respond with a status of that batch, it assumes the server never received it and remarks those items for another upload attempt. If it hears back, it processes the success and failure line by line and then marks the items on the mobile device accordingly. If the mobile device doesn't ask about the log in the next upload, the server assumes the batch's lifecycle is complete and it no longer needs to maintain that log. It is then deleted.
The server doesn't delete a log until it has a successful request from the specific device no longer asking to hear about the log. So if I have log 1 on the server and the device doesn't ask in the next upload to hear back about that log, the server then removes that log assuming the device got the response it wanted or doesn't care about it anymore.
Related
I am using firestore with queries and i am getting data but something in network tab is loading none stop
as you can see its over a minute
should i be concerned about it?
It's hard to be certain without seeing the code that produces this problem, but most likely you're using a realtime listener (onSnapshot) in your code.
Such a listener keeps an active , open connection between the client and the server, so that the database can send a notification to the client when the data changes. The Chrome network tool shows this as a content download, because indeed data trickles in over this connection.
So likely what you're seeing is a normal part of Firestore's protocol for realtime, bi-directional communication between the client and server, but again.
Scenario: WPF application that sends a file to a server and the server, in turn, performs a series of validations that can take several minutes, during which the server sends a series of messages to tell the application what it is doing (signalr), in at the end of everything, it warns that the process has ended.
What I'm doing: Every time the application is sending a new file I start the hub await hubConnection.Start() and at the end of it all I stop.
The process consists of: doing some local validations, sending the file to the server, monitoring the processing (signalr) and at the end, if applicable, downloading a file with the error;
It's all working fine, but I'm afraid something might go wrong along the way, flag not sending the messages, etc.
My question: What is the correct way to do this? When should I connect the hub (await for hubConnection.Start())? Should I do this when starting the app? How do I receive the messages later (in each message I have an identifier of the file I am working on)?
I'm trying to set up the email receiver found here, to process incoming emails and send them out as POST data to a script on my server to be handled further from there. The issue I'm having is when I send one test email to foo#[myappname].appspotmail.com, the App Engine logs show that the email is continually "received" over and over again every couple of minutes, even though I only sent it once. Then after several minutes of this, when I go into settings and disable the app, I get at least one "Delivery to the following recipient failed permanently" message to the email account I was sending the emails from (makes sense, since the app is now disabled and not accepting any incoming mail).
What I'm having trouble understanding is why the application is behaving like it's getting multiple emails sent to it when it's only one. Do I need to modify the Python script to do something to delete or halt the email once it's been processed the first time? If so, does anyone have any suggestions as to how to do that? The Python script that I'm using is found here.
User voscausa answered my question-- the email requests kept retrying because the script was erroring. Thanks!
Background
We currently have a SilverLight form that posts data to a second common form that multiple applications use, which then runs the need business logic to place the data into a database.
We have several national and international offices where this form is used.
There is one office location (CO) where this form is consistently producing intermittent error messages and based off log data, it is only happening in this office.
Error Symptoms
Initially users will typically report that there is an error and when I log into their machine using MS Communicator, 80% of the time it would start working.
I started installing Fiddler on their machines to try and capture more information but 100% of the time I did that, the form started posting successfully. The users being resourceful, simply start Fiddler anytime the form doesn't post and it works fine.
I also asked users to go through Citrix which is hosted in the TX office and the form posts fine.
Error Details
I used OPNET to better monitor the traffic and I found that when user's simply open IE the authentication handshake fails.
Client => Server = 401
Client <= Server = Authentication Token
Client does not respond
When we use fiddler, the handshake is successful.
The error returned by SilverLight was a very generic [HttpWebRequest_WebException_RemoteServer] message.
Question
What would cause the handshake to work sometimes by itself, always with fiddler and CITRIX, and sometimes it doesn't.
we wrote in C++ a screen sharing application based on sending screenshots.
It works by establishing a TCP connection btw the server and client, where the server forwards every new screenshot received for a user through the connection, and this is popped-up by the client.
Now, we are trying to host this on google app engine, and therefore need 'servlet'-ize and 'sandbox' the server code, so to implement this forwarding through HTTP requests.
I immagine the following:
1. Post request with the screenshot as multiple-data form (apache uploads ..).
But now the server needs to contact the specified client (who is logged in) to send it/forward the screenshot.
I'm not sure how to 'initiate' such connection from the servlet to the client. The client doesn't run any servlet environment (of course).
I know HTTP 1.1 mantains a TCP connection, but it seems gapps won't let me use it.
1 approaches that comes to mind is to send a CONTINUE 100 to every logged in user at login, and respond with the screenshot once it arrives. Upon receival the client makes another request, and so on.
an alternative (insipired from setting the refresh header for a browser) would be to have the app pool on a regular basis (every 5 secs).
You're not going to be able to do this effectively on GAE.
Problem 1: All output is buffered until your handler returns.
Problem 2: Quotas & Limits:
Some features impose limits unrelated
to quotas to protect the stability of
the system. For example, when an
application is called to serve a web
request, it must issue a response
within 30 seconds. If the application
takes too long, the process is
terminated and the server returns an
error code to the user. The request
timeout is dynamic, and may be
shortened if a request handler reaches
its timeout frequently to conserve
resources.
Comet support is on the product roadmap, but to me your app still seems like a poor fit for a GAE application.
Long Polling is the concept used for such asynchronous communications between server and client.
In Long Polling, servlet keeps a map of client and associated messages. Key of Map being client id and value being list of messages to be sent to the client. When a client opens a connection with server (sends request to a servlet), the servlet checks the Map if there are any messages to be sent to it. If found, it sends the messages to the client exits from the method. On receiving messages, the client opens a new connection to the server. If the servlet does not find any messages for given client, it waits till the Map gets updated with messages for given client.
This is a late reply, I'm aware, but I believe that Google have an answer for this requirement: the Channel API.