My skill has some intents which give out very large reponses (text). So there is a good chance the user might want to interrupt it and listen to the remaining part of the response later. I want to make the intent continue from where it left off (I guess I will have to use user state management). Is there a way for the backend to know where it was interupted? or even better, is there a way to send the response line by line so that the backend exactly knows which line was read out last?
Currently there is no way to find where the speech was interrupted nor you can send multiple responses line by line. However, you could calculate the time difference between when the response was sent and the interrupted request was received. And based on the time difference you could roughly determine where was it interrupted. Again, this is not an accurate way, it just a hack and you should keep in mind the network latency.
When you send the response, include response generated timestamp in sessionAttributes, so that you can use it to verify time difference.
Related
we are building-up a application with chat system as a part of our service, for that, we are using websockets, as it is easily available on all platform(ios,android,web).
But we need to store all the messages received from the websockets.
We realized websockets are extremely fast, so if fire a query, for each messages we received through the websockets there might be a
some chances, some messages would not be store/or get might be
lost.
let me explain these:
Case1
so in one-to-one chat, when we receive a message, we store in a variable called $msg and we simply pass this $msg to the intended user. So if we add some more logic, like before sending message to user, we could fire a query to store the message, it would take some time, lets say 2sec, or 1 sec, with this logic, some messages received through the sockets will be lost,
so we have to have deliver the message as soon as we received.
Case2
there could be another logic; if we fire a query, after sending the message to the intended user, in that time, there could be a chance $msg variable has changed their value so many times, in just fraction of second.
lets see an example.
lets assume, The variable $msg has 'hello' and we pass this $msg variable to the function, who stores the message to the database, but as we know, websockets are extremely fast, there could be chance, the value stored in the $msg, has changed so many times, or we have lost our message 'hello' which we wanted to store.
could we implement the Message Queue(DS MESSAGE QUEUE) in that case, or we should use apache kafka, rabbitmq like services ?
Note: we already aware with some real time database concepts, provides
by tech giants, but due to its high cost we are not able to use such
kind of services.
First i would like to apologize for my bad english, I wish you will understand my problem.
Here's my question, for my internship, I need to create a fonctionality that allows a caller to put his call in waiting, with a button, and to take the call back with that button again. And i think there's an option with SIP protocol that allows to do that, but i just can't find it, i searched in internet in some documentations, the only thing I might know and i'm not even sure is that it could be an option in a re-INVITE request, that can be send by the called or the caller one, if someone could help me ?
Thanks
The feature you are looking for is achieved by implementing the Call Hold Scenario on a SIP Call.
there are 3 ways to put the call on hold at the press of the button.
Generate a Re-INVITE SDP with SendOnly option - the answer shall contain a recvonly and in this case you can go ahead and inject hold music media through the rtp stream.
Sending inactive in the Re-INVITE SDP which basically puts the media inactive for the session. This is when no rtp exchange is desired.
Sending the 0.0.0.0 notation for the Re-INVITE SDP - This is the old deprecated format of call hold when IPV4 was still the norm [still is!!] but it makes sure the RTP doesn't have a ip to be sent.
All of these mechanisms rely on the basic methods and hence it shouldn't be very difficult to achieve using any client software.
I am trying to figure out how to make a request in c each n seconds. I want it to be asynchronous, meaning the requests are made even if the previous ones have not been responded.
I want to achieve this in order to test a server.
Any ideas?
Thank you.
Use the multi interface. Add a new handle and start a new request every N seconds and let it take its time. It'll handle "any" amount of simultaneous transfers for you. "any" because there's probably a limit in number of open sockets a process is allowed to use (depending on the environment you want this for).
everyone, I am porting the WinPcap from NDIS6 protocol to NDIS6 filter. It is nearly finished, but I still have a bit of questions:
The comment of ndislwf said "A filter that doesn't provide a FilerSendNetBufferList handler can not originate a send on its own." Does it mean if I used the NdisFSendNetBufferLists function, I have to provide the FilerSendNetBufferList handler? My driver will send self-constructed packets by NdisFSendNetBufferLists, but I don't want to filter other programs' sent packets.
The same as the FilterReturnNetBufferLists, it said "A filter that doesn't provide a FilterReturnNetBufferLists handler cannot originate a receive indication on its own.". What does "originate a receive indication" mean? NdisFIndicateReceiveNetBufferLists or NdisFReturnNetBufferLists or both? Also, for my driver, I only want to capture received packets instead of the returned packets. So if possible, I don't want to provide the FilterReturnNetBufferLists function for performance purpose.
Another ressembled case is FilterOidRequestComplete and NdisFOidRequest, in fact my filter driver only want to send Oid requests itself by NdisFOidRequest instead of filtering Oid requests sent by others. Can I leave the FilterOidRequest, FilterCancelOidRequest and FilterOidRequestComplete to NULL? Or which one is a must to use NdisFOidRequest?
Thx.
Send and Receive
A LWF can either be:
completely excluded from the send path, unable to see other protocols' send traffic, and unable to send any of its own traffic; or
integrated into the send path, able to see and filter other protocols' send and send-complete traffic, and able to inject its own traffic
It's an all-or-nothing model. Since you want to send your own self-constructed packets, you must install a FilterSendNetBufferLists handler and a FilterSendNetBufferListsComplete handler. If you're not interested in other protocols' traffic, then your send handler can be as simple as the sample's send handler — just dump everything into NdisFSendNetBufferLists without looking at it.
The FilterSendNetBufferListsComplete handler needs to be a little more careful. Iterate over all the completed NBLs and pick out the ones that you sent. You can identify the packets you sent by looking at NET_BUFFER_LIST::SourceHandle. Remove those from the stream (possibly reusing them, or just NdisFreeNetBufferList them). All the other packets then go up the stack via NdisFSendNetBufferListsComplete.
The above discussion also applies to the receive path. The only difference between send and receive is that on the receive path, you must pay close attention to the NDIS_RECEIVE_FLAGS_RESOURCES flag.
OID requests
Like the datapath, if you want to participate in OID requests at all (either filtering or issuing your own), you must be integrated into the entire OID stack. That means that you provide FilterOidRequest, FilterOidRequestComplete, and FilterCancelOidRequest handlers. You don't need to do anything special in these handlers beyond what the sample does, except again detecting OID requests that your filter originated in the oid-complete handler, and removing those from the stream (call NdisFreeCloneOidRequest on them).
Performance
Do not worry about performance here. The first step is to get it working. Even though the sample filter inserts itself into the send, receive, and OID paths; it's almost impossible to come up with any sort of benchmark that can detect the presence of the sample filter. It's extremely cheap to have do-nothing handlers in a filter.
If you feel very strongly about this, you can selectively remove your filter from the datapath with calls to NdisFRestartFilter and NdisSetOptionalHandlers(NDIS_FILTER_PARTIAL_CHARACTERISTICS). But I absolutely don't think you need the complexity. If you're coming from an NDIS 5 protocol that was capturing in promiscuous mode, you've already gotten a big perf improvement by switching to the native networking data structures (NDIS_PACKET->NBL) and eliminating the loopback path. You can leave additional fine-tuning to the next version.
How can I fetch the avatars of all the contacts in a user's XMPP/Jabber roster?
I have previously asked this question, and while implementing the <presence> handler, I noticed that the presence items my app receives are of the form:
<presence to="me" from="contact">
...some other stuff here...
<x xmlns="vcard-temp:x:update"><photo>3FB991AA97D7701C21EAFE65FB866E4BFF1B927C</photo></x>
</presence>
The 3FB991AA97D7701C21EAFE65FB866E4BFF1B927C part looks like a SHA hash to me, but how can I get the actual avatar of the user in question?
vCard-based Avatars are specified in XEP-0153. You are correct that the photo element contains a SHA1 hash. Request the vCard of the person that sent you the hash:
<iq to='juliet#capulet.com'
type='get'
id='vc2'>
<vCard xmlns='vcard-temp'/>
</iq>
And fish the photo out of the response:
<iq to='romeo#montague.net/orchard'
type='result'
id='vc2'>
<vCard xmlns='vcard-temp'>
<PHOTO>
<TYPE>image/jpeg</TYPE>
<BINVAL>
Base64-encoded-avatar-file-here!
</BINVAL>
</PHOTO>
</vCard>
</iq>
You MUST cache based on that if you're going to use this protocol, and you'll really want to throttle how often you ask for avatars when you start up (particularly the first time a user logs in). Grabbing bajillions of avatars in a short amount of time will likely get you rate-limited by your server otherwise.
Also, be very careful about calculating your SHA1 hash. I've seen several clients that aren't terribly careful, who end up in an endless loop re-requesting the same avatar over and over.
I suggest negative-caching if you request an avatar and it doesn't match the hash you expect; cache the fact that you aren't going to get an answer for that hash, and don't ask for it again next time. The sender's SHA1 logic is likely wrong in some interesting way, and it's not going to get better the next time you ask.
Finally, some clients are written to try asking the sender's server for vCard data using XEP-0054 first as XEP-0153 says, then fall back on asking the sender's client directly by sending an IQ get for the vCard to the sender's full JID (user#domain/resource). Be prepared to deal with those requests on the sender's side.