I followed the guide in Delphi Labs: Datasnap XE - Callbacks ,
Callbacks seems to work good. Yet, leaving the client sides idle for more than a hour -- seems to cause clients callbacks stop working. I changed the server DSTCPServerTransport.KeepAliveEnabled, .KeepAliveInterval, .KeepAliveTime -- but it didn't help in any way.
Does anyone know how can I keep the clients connected overtime?
1: https://edn.embarcadero.com/article/41374
I also use Datasnap callbacks in several applications. My solution was to setup a timer that measures how long it takes for a specific message (eg '*ping') that was sent using BroadCastToChannel to be received by a registered callback on the same channel in the same application. I allow for 5 seconds in a mobile application, and if the echo of my ping isn't received in that time, I assume my callback isn't working anymore. I do what I call "recycle the callback". That is, I de-register the previous callback (causes no errors if it fails) and register a new one (my callback id's are timestamp based so they are all unique). My "ping timer" runs on 1 minute intervals which is often-enough for my application(s). This solution would be a lot of code to present here, so I hope my description will help you find a solution that works for you. Ask questions if you're unsure.
Related
For a game website, I want a player to contest either agains a human or an AI.
I am using Django + Channels (Django-4.0.2 asgiref-3.5.0 channels-3.0.4)
This is a long way of learning...
Human vs Human: the game take place is the web browser turn by turn. Each time a player connects, it opens a websocket connexion, a move is sent through the socket, processed by the consumer (validated and saved in the database) and sent to the other player.
It is managed only with sync programming.
Human vs AI: I try to use the same route as previously. A test branch check if the game is against the computer and process a move instead of receiving it from the other end of the websocket. This AI move can be a blocking operation as it can take from 2 to 5sec.
I don't want the receive method of the consumer to wait for the AI to return its move, since I have other operations to do quickly (like update some informations on the client side).
Then I thought I could easily take advantage of the allegedly already existing event loop of the channels framework. I could send the AI thinking process to this loop and return the result later to the client through the send method of the consumer.
However, when I write:
loop = asyncio.get_event_loop()
loop.create_task(my_AI_thinking())
Django raises a runtime effort error (the same as described here: https://github.com/django/asgiref/issues/278) telling me there is no running event loop.
The solution seemed to be to upgrade asgiref to 3.5.0 which I did but issue not solved.
I think I am a little bit short of background, and some enlightments should help me to understand a little bit more what is the root cause of this fail.
My first questions would be:
In the combo django + channels + asgi: which is in charge to run the eventloop?
How to check if indeed one event loop is running whatever the thread?
Maybe your answers wil raise other questions.
Did you try running your event_loop example on Django 3.2? (and/or with different Python version)? I experienced various problems with Django 4.0 & Python 3.10, so I keep with Django 3.2 and Python3.7/3.8/3.9 for now, maybe your errors are one of these problems?
If you won't be able to get event_loop running, I see two possible alternative solutions:
Open two WS connections: one only for the moves, and the other for all the other stuff, such as updating information on Player's UI, etc.
You can also use multiprocessing to "manually" send calculating AI move to other thread, and then join the two threads again, after receiving the result (the move). To be honest, multiprocessing in Python is quite simple -- it's pretty handy, if you are familiar with the idea of multithreaded applications.
Unfortunately, I have not yet used event loops in channels myself, maybe someone more experienced in that matter will be able to better address your issue.
I wants to do some operations even after closing the session (manual or by instant). I can do whatever I want when the user clicking the link 'logout' but I don't see any option do the same when the user suddenly closing the browser.
Hence, I am looking for any listener kind of things similar in Java.
in Java:
http://www.mkyong.com/servlet/a-simple-httpsessionlistener-example-active-sessions-counter/
Rails is stateless and doesn't support this type of behaviour directly.
If your requirement can only be satisfied with this type of logic, then I can think of a number of ways you could work around this:
Have the page continuously ping your server to let it know the
connection is still alive. Run a cron job every reasonable interval
to take whatever action you want on terminated sessions.
Or just say that any session not refreshed after 30 minutes or
something is considered terminated.
Create a javascript code run on page unload that notifies your app that
the browser is closing. This is obviously not foolproof (connection
drops, browser crashes, etc) and probably isn't viable.
I have an exception handler that runs when my code crashes, but I also need to send a msg to the server (parse.com) when this happens to let the server know the player has stopped playing,
void onUncaughtException(NSException *exception)
{
NSLog(#"uncaught exception: %#", exception.description);
[self playerLoggedOut];
}
The playerloggedOut line gives the error of undeclared identifier self.
How can I run the playerLoggedOut method when the exception happens?
How can I run the playerLoggedOut method when the exception happens?
You're not going to be able to start some lengthy process like establishing a network connection and sending a message. Your best strategy might be to save the information and send it when the app starts up again so that the server can update its records or whatever. Alternatively, have the client check in with the server every t seconds; if the server doesn't hear from the client within some interval like 2t, it assumes that the client has stopped functioning.
First of all: self is unknown, because you are not in a method, but a function. Functions do not run in an object context, therefore do not know self.
As mentioned before by Caleb, you should have a watch dog on server-side that automatically logs a player out, if the server gets no messages from the client for a while (in terms of seconds). To prevent from being logged out automatically, when the user is deactive (but still playing), you can implement a heart beat on the client using an instance of NSTimer.
As others have stated, don't try to do expensive things like talk to the Parse server in your exception handler.
In regards to what you are actually trying to achieve, you might want to re-think your architecture.
In the sometimes-connected world of mobile devices you will have your connection come and go. Instead of a boolean flag of IsLoggedIn, consider a UTC Date Time of LastUserActivity, and use a rule that says they are considered logged in if that last activity is in the last 5 minutes, or whatever is suitable.
If all access to Parse is done via Cloud Code then you could easily add a function call that sets the LastUserActivity to each method, then you can also avoid issues with time sync since you'll always be using the server's clock.
If you want to get a list of all online users, you can then just query for where LastUserActivity is greater than 5 minutes ago (or whatever limit you set).
OK - let's rephrase this whole question shall we?
Is there any way to tell if iOS is holding onto an NSURLConnection after it has finished & returned it's data?
I've got 2 NSURLConnections I'm instantiating & calling into a server with. The first one initiates the connection with the server and then goes into a COMET style long-polling wait while another user interacts with the request. The second one goes into the server and triggers a cancel mechanism which safely ends the first request and causes both to return successfully with a "Cancelled by you" message.
In the happy path case the Cancel button will never be clicked. But it's possible to click it and exit the current action.
This whole scenario works GREAT once. And then never works again (until the app is reset).
It's as though the first time thru one of the connections is never released and we are from then on limited to only a single connection because one of them is locked.
BTW I've tried NSURLConnection, AFNetwork, MKNetworkKit, ASIHTTPRequest - no luck what-so-ever with any other frameworks. NSURLConnection should do what I want. It's just ... not letting go of one of my connections.
I suspect the cancellation request in Step 2 is leaving the HTTP connection open.
I don't know exactly how the NS* classes work with respect to the HTTP/1.1 recommendation of at most two simultaneous connections, but let's assume they're enforcing at most two connections. Let's suppose the triggering code in Instance A (steps 1 and 3 of your example) cleans up after itself, but the cancellation code in Instance B (steps 2 and 4) leaves the connection open. That might explain what you are observing.
If I were you, I'd compare the code that runs in step 1 against the code that runs in step 2. I bet there's a difference between them in terms of the way they clean up after themselves.
If I'm not wrong,
iOS/Mac holds on to a NSURLConnection as long as the "Keep-Alive" header dictates it to.
But as a iOS developer you shouldn't be worried. any reason why you would like to know that?
So unfortunately with the lack of a real solution to this issue being found in all my testing I've had to implement simple polling to resolve the issue.
I've also had to implement iOS only APIs on the server.
What this comes down to is an API to send up a command and put it into a queue on the server, then using an NSTimer on the client to check the status of the of the queued item on a regular interval.
Until I can find out how to make multiple connections on iOS with long-polling this is the only working solution. Once I have a decent amount of points I'll gladly bounty them away for a solution to this :(
I'm designing a .net interface for sending and receiving a HL7 message and noticed on this forum theres a few people with this experience.
My question is.... Would anyone be able to share their experience on how long it could take to get a message response back from a hospital HL7 server. (Particularly when requesting patient demographics) - seconds / minutes / Hours?
My dilemma is do I design my application to make the user wait for the message to come back.
(Sorry if this is a little off topic, it’s still kinda programming related? – I searched the web for HL7 forums but got stuck so again if anyone knows of any please let me know )
cheers,
Jason
In my experience, you should receive an ACK or NAK back within a few seconds. The receiving application shouldn't do something like making you wait while it performs operations on the message. We have timeouts set to 30 seconds, and we almost never wait that long for a response.
This is quite dependent on the kind of HL7 message sent, typically messages like ADT's are sent as essentially updates to the server, and are acknowledged almost immediately if the hospital system is behaving well. This will result in a protocol level acknowledgement, which indicates that the peer has received the message but not necessarily processed it yet.
Typically, most systems will employ a broker or message queue in their integration engines so you get your ack almost immediately.
Other messages like lab request messages may actually send another non-ack message back which contains the information requested. These requests can take longer.
You can check with the peer you're communicating with to see what integration engine they are using, and if a queue sits on that end which would help ensure the response times are short.
In the HL7 integration tool I work on, we use queues for inbound data so we can responde immediately. And for our outbound connections, 10s timeouts are default, and seem to work fine for most of our customers.
When sending a Query type event in HL7, it could take a number of seconds to get the proper response back. You also need to code for the possibility that you will never get a response back, and the possibility that connected systems "don't do" queries.
Most HL7 nets that I have worked on, assume that all interested systems are listening for demographic updates at all times. Usually, receiving systems process these updates into a patient database that documents both the Person and Encounter (Stay) information on the fly.
In my location, my system usually gets about 10-20 thousand messages a day, most of which are patient demographic updates.
It depends if the response is generated automatically by a system or if the response is generated after an user does something on the system. For an automatic response it might take less than a second, depending of course on the processing that is done by the system and the current work load of that system. If the system is not too busy and processing is just a couple of queries and verification of some conditions, considering network delays, response time should be a few seconds or less.