What is the proper way to send multiple remote requests in CAN2.0B/A? Is it usual to have some delay between them like 1/50s, for the receiver to react? I know it shouldnt be needed if proper interrupts are used, i just want to do it the way it is originally designede for.
For future people, no delay is usually needed, be aware an answer can be received while sending remote requests.
Related
This might be very basic questions but I have spent enough time to explore the possible solutions. In my project, I am successfully getting status info via service request. I want to add a continuous observer for any state change on the server. I am not sure if the server is setup to push silent notifications. It appears KVC/KVO or Notifications only observers changes in objects. How can I elegantly approach this problem to refresh my view only when the status changes on the server?
You can poll the server continuously, or in my opinion, a much better solution is to use WebSockets. There's a variety of libraries out there for both iOS and server-side.
I approach such a development task like this:
Use the performSelectorInBackground:withObject: method to create a concurrent thread.
Use an NSURLConnection to perform an HTTP GET operation (synchronously) against your server, allowing the thread to block until a reply arrives.
Use an NSEvent object to notify the main thread when a response is available for inspection.
Repeat the above, as needed.
For state changes that occur less frequently, I would use the Apple Push Notification Service to send state change information to my app, without the need for continuous polling.
Most server framework/examples using sockets and I/O completion ports makes notifications in a way I couldn't completely figure out the purpose.
Upon read packets are processed, usually they are reordered to circumvent thread scheduling issues processing packets out of order no matter IOCP ensure a FIFO queue.
The problem is when a socket is closed gracefully or by an error. I saw in both situation, and again by the o.s. thread scheduler, the close notification may be sent to the application (i.e. http server using the framework) "before" the notification of data previously readed.
I think that the close notification should be queued in such way so the application receives it after previous reads.
Is there any intended use in most code I saw or my behavior may be correct depending on the situation?
What you suggest makes sense and I would imagine that any code that handles graceful close (a read returning 0 bytes) would do so by processing it after any proceeding successful read. Errors coming out of GetQueuedCompletionStatus(), such as connection reset errors, etc, are harder to integrate into the receive flow as they occur out of band as far as the receive data is concerned. Your question's a bit vague and depends very much on the code you're using and how you (or the people who wrote that code) want to handle these things. There is no single correct way, IMHO.
RFC 3501 states in section 6.1.2. that you should use the NOOP command for polling.
Though in TIdIMAP4 there's only the KeepAlive method using it, which is implemented as a procedure, i.e. doesn't return anything.
So how to check for status updates like e.g. new messages or read status changes? I.e. how can I do manual polling with TIdIMAP4? Which methods and properties are involved in doing that? And how to get the (U)IDs these messages?
Or is it even possible to use the IDLE command specified in RFC 2177 to avoid polling and to get updates automatically?
IMAP is technically an asynchronous protocol, but TIdIMAP4 is currently implemented as a synchronous client. As such, unexpected/out-of-order data is either discarded, treated as untagged data, or treated as error data, depending on timing and context. Untagged/extra data is accessible from the TIdIMAP4.LastCmdResult property, which you can type-cast to TIdReplyIMAP4 to access its Extra sub-property.
IDLE is not currently supported in TIdIMAP4. There are tickets in Indy's issue trackers (see here and here) to add IDLE support in a future release, maybe in Indy 11. Until then, you will have to poll the mailbox envelopes periodically, keeping track of messages you have already seen so you can detect new messages.
Yes, you can use IDLE to avoid NOOP and in general it's a good idea.
However, that won't give you any results. In a way, IMAP commands don't have results. They tell the server what you want, and the server tells you things. The server is free to tell you things for other reasons as well, including the goodness of its heart.
You might say that NOOP means "hi server, now is a good time to tell me things, I'm listening" and IDLE means "hi server, I'm listening all the time, so just tell me whatever you want whenever you want". Both also mean "and btw, restart your inactivity timeout if you have one".
The server will send you EXISTS, FETCH and other responses, which I expect TIdIMAP4 forwards to you in some way. (Yes, they're called responses even though they're not in response to any command of yours. They may be sent in response to someone else having sent you mail, for instance. Stupid naming.)
I have a Rails Controller on Heroku where I send emails in a loop, and respond to the user with some information on which email address the emails were sent to.
While this works when only a few (~40) emails need to be sent out, the request times out when more there are more than just a few emails to be sent out (e.g. > 40).
Heroku states in their guides that requests must respond with at least one byte within 30 seconds: https://devcenter.heroku.com/articles/request-timeout
While I know this is not the best way to achieve this, I'm currently trying to figure out how to do this in Ruby.
If this were a PHP app, I could do an echo before entering the loop, and then keep echoing something in every iteration. How do I achieve something similar in rails?
Your best bet is to not do the mailing before sending the response back. You will have better luck first adding the job to one of Heroku's many available worker queues, then kicking to a monitoring page that displays the job progress and updates itself periodically. If you are trying to avoid using one of those queue services, for budget reasons, you may be able to accomplish the same thing using a new thread, instead of a queue. Either way, this technique will scale better, as well as being able to recover from failure more easily as well.
As you appear to already know that your proposed solution is not the ideal solution, I will also try to answer your exact question. You may be able to make HTTP streaming work for this. I would recommend checking out http://railscasts.com/episodes/266-http-streaming.
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.