I am trying to setup some ServiceListeners, in particular two:
zeroConf.addServiceListener("100.1.168.192.in-addr.arpa.", myListener);
zeroConf.addServiceListener("_workstation._tcp.local.", myListener);
Whenever I do this, I get callbacks for myListener on serviceResolved() and serviceAdded() for all services that match "_workstation._tcp.local." However, I get no callbacks for "100.1.168.192.in-addr.arpa." ... despite the fact that jmDns sends out the queries, and a response comes back! I've attached a tcpdump of the request packets that jmdns sends out, and the response that comes back for it. However, the callbacks are not called so I never see the response in my application.
Does anyone know why this might be happening?
http://users.ece.cmu.edu/~gnychis/jmdns_nocallback.pcap
After some debugging of the actual event type that comes in, the event type resolves to "_tcp.in-addr.arpa." Adding this to my service listeners triggers the call back.
Related
[Edited. Added code sample and more explanations]
Is anybody familiar with the GA4 Measurement Protocol?
We are sending events from our backend servers to the server-side GTM container using the GA4 Measurement Protocol. Everything works fine except for conversion tracking. The events marked as conversion are not counted as conversions if we send those via MP (except for the default "purchase" event, it works perfectly). The same event with the same parameters counts as a conversion if we send it from the browser (client-side GTM). As I couldn't find anything about this issue online, the only thing left was to debug parameter by parameter using the server-side GTM preview mode. Here I discovered, that if I send events from the browser, the requests for events I mark as conversions in GA have "&_c=1" in their query string.
That means, as far as I understand it, that in order to get conversion events via MP, the event request needs to have "_c" query string parameter. I tried adding "_c" as an event param, but that didn't work. Is there a designated JSON parameter to mark the event as a conversion?
------------MORE INFO--------------
Here is an example of an event "Experts". This event gets sent from both the client-side and the server. As you can see in the screenshot, this event is marked as a conversion.
As you can see on the second screenshot, the actual events (137) are much more than the conversions detected (48). The difference are exactly the ones sent from the server-side.
Here is the request body of the server call:
{
"client_id":"Z9TLWnyVC2UK4UssPIVk8J+2n5BZhgWLtWSlFYYSwlg=.1642076344",
"user_id":"119412",
"events": [{
"name": "Experts",
"params": {
"tenweb_action": "[Test action]",
"tenweb_info": "[Some more info]",
"debug_mode":1,
"page_location": "https://10web.io/[some-test-page]"
}
}]
}
#Jan, #DaImTo, and everyone else that might have this issue in the future.
I think I've found a solution. Although it's unofficial and might break at any moment, it's the best one I've found so far. Here is what I ended up doing. While debugging via GTM preview mode I noticed, that in Event Data tab of conversion events there is an object "x-ga-system_properties", that, among other system variables, contains c:"1" . So I tried adding
"x-ga-system_properties":{"c":"1"}
to the event parameters JSON that we send to the Measurement Protocol endpoint of our server-side GTM.
IT WORKED. The events sent that way were registered as conversions by GA4.
Would be great to hear your thoughts on this. Do you think it's a stable solution? Do you think there will be official documentation on this from Google?
APIClient?.update(Record, completion: { response, error in
dLog(response)
dLog(error)
})
We've been trying to work through a buggy API that is provided by another company. Sometimes, the API works and I get a response record. Occasionally, the update disappears into a blackhole and completion never gets called, so I don't get an error either.
Ultimately we want the API to be fixed, but what is the correct way to catch this in the meantime so I can popup an alert?
I've used XCTest/expectation/waitFor, but I think that's mainly for Unit Testing, not sure if that could apply here.
We use the cumulocity REST API. Regular real time notifications work, e.g. we subscribe to /alarms/*, start our connection/polling loop and when we create an alarm we receive the expected JSON. We did not install any specific modules or statements, it just works.
But when we try to do the same with SmartREST we receive this error, as soon as the alarm is created:
40,,/alarms/177649296,Could not find any templates subscribed for the channel
Following the reference guide (http://cumulocity.com/guides/reference/smartrest/) we tried it like this, where all requests have the same X-Id-header and all requests result in the expected http status 200 and no error messages, except for the last one:
Register a smart response template by doing a POST to /s
Body: 11,102,,,$.channel
Handhake: POST to /cep/realtime
Body: 80
Response is our clientId (e.g. 191het1z38bp7iq1m96jqqt8jnef)
Subscribe: POST to /cep/realtime
Body: 81,191het1z38bp7iq1m96jqqt8jnef,/alarms/*
Connect: POST to /cep/realtime
Body: 83,191het1z38bp7iq1m96jqqt8jnef
In the normal REST case the notification consists of a JSON array with 2 elements, both of which have a property "channel". So that is what we would expect from our response template. Instead, we get the aforementioned error 40.
Is our response template wrong? Is it not properly matched by the X-Id? What does it mean, that there are no "templates subscribed for the channel"? The subscriptions are done for a clientId, and not for a specific response template, and the templates are supposed to be matched automatically anyway. So probably "template" means "X-Id" here? The documentation seems ambiguous as to the meaning of that word. But anyway, we did use the same X-Id header in all of the requests.
Any pointer about what we're doing wrong would be appreciated, since we tried pretty much anything by now.
The SmartREST protocol was developed for a IoT-device <-> platform communication. So there was never any design around using it to subscribing to realtime data (except of course for the operations a device needs) as usually devices to not need subscribe to the data that they created themselves.
That said it is possible to use it but with a couple of limitations. Your approach is basically correct but there is one problem with the subscription. The wildcard subscriptions will not work with SmartREST because on subscription it links your X-Id with the channel you subscribed to but there is never a message published on the channel /alarms/*. Thus this kind of weird error message that said that there was no template subscribed for the channel the alarm appeared on. Inside CometD you still receive the alarm because of the wildcard subscription but the SmartREST part does not work.
The messages are published on the channel with the deviceId (e.g. /alarms/12345).
If you subscribe to /alarms/12345 it will work. You can of course subscribe to as many channels as you want but wildcard subscription won't work.
Regarding the templates you need to know the following. The SmartREST parsing is not done on the raw JSON of CometD but on the payload inside it (e.g. the alarm). So a template for an alarm could look like this:
11,500,,$.severity,$.id,$.type,$.severity
This would trigger only if the object has a severity and would return id, type and severity.
I've been playing around with building some realtime functionality using Sails.js version 0.10-rc5 (currently the #beta release).
To accomplish anything, i've been following the sweet SailsCast tutorial on this subject (sailsCast link)
It talks about subscribing to a model via a 'subscribe' action within the model's controller. Then listening to it at the client side, waiting for the server to emit messages. Quite straightforward, although I do not seem to receive any messages.
I'm trying to do this to get real-time updates on anything that changes in my User models, or if new ones get created.. So I can display login status etc. in real time. Pretty much exactly the stuff that's explained in the sailsCast.
In my terminal i'll get two things worth noticing, of which the first is the following:
debug: Deprecated: `Model.subscribe(socket, null, ...)`
debug: See http://links.sailsjs.org/docs/config/pubsub
debug: (⌘ + double-click to open link from terminal)
debug: Please use instance rooms instead (or raw sails.sockets.*() methods.)
It seems like the 'subscribe' method has been deprecated. Could anybody tell me if that's correct, and tell me how to fix this? I've been checking out the reference to the documentation in the debug message, although it just points me to the global documentation page. I've been searching for an answer elsewhere, but haven't found anything useful.
The second message I'm getting is:
warn: You are trying to render a view (_session/new), but Sails doesn't support rendering views over Socket.io... yet!
You might consider serving your HTML view normally, then fetching data with sockets in your client-side JavaScript.
If you didn't intend to serve a view here, you might look into content-negotiation
to handle AJAX/socket requests explictly, instead of `res.redirect()`/`res.view()`.
Now, i'm quite sure this is because I have an 'isAuthenticated' policy added to all of my controllers and actions. When a user is not authenticated, it'll redirect to a session/new page. Somebody must log in to be able to use the application. When I remove the 'isAuthenticated' policy from the 'subscribed' action, the warnings disappear. Although that means anyone will get updates via sockets (when I get it to work), even when they're logged out. - I don't really feel like people just sitting at the login screen, fishing out the real time messages which are intended only for users who are logged in.
Can anyone help me getting the real time updates to work? I'd really appreciate!
As far as the socket messages not being received, the issue is that you're following a tutorial for v0.9.x, but you're using a beta version of Sails in which PubSub has gone through some changes. That's covered in this answer about the "create" events not being received.
Your second issue isn't about sockets at all; you'll just need to reconsider your architecture a bit. If you want to to use socket requests to sign users in, then you'll have to be more careful about redirecting them because, as the message states, you can't render a view over a socket. Technically you could send a bunch of HTML back to the client over a socket, and replace your current page with it, but that's not very good practice. What you can do instead is, in your isAuthenticated policy, check whether the request is happening via sockets (using req.isSocket) and if so, send back a message that the front end can interpret to mean, "you should redirect to the login page now". Something like:
module.exports = function (req, res, next) {
if ([your auth logic here]) {
return next();
}
else {
if (req.isSocket) {
return res.json({status: 403, redirectTo: "/session/new"});
} else {
return res.redirect("/session/new");
}
}
}
My code is for sending Emails to multiple users.User will click on send button,and rpc will be called. Now if user clicks on Cancel button .Ongoing rpc should be cancelled. . Can anyone help ?
I googled a lot, they have introduced the concept of Request Builder. But I am not getting any perfect idea.
Make your async method return a Request instead of void so you can call cancel() on it.
For the same reason, asynchronous methods do not have return types; they generally return void. Should you wish to have more control over the state of a pending request, return Request instead.
— Source: https://developers.google.com/web-toolkit/doc/latest/DevGuideServerCommunication#DevGuideCreatingServices
FYI, you can also use RequestBuilder as the return type, you'll then have to call the send() method by yourself (after possibly customizing the request, e.g. adding headers) to actually make the request to the server.
And of course, if you need to tell the server to abort the processing, you'll have to make another RPC call.
The request is asynch, so the client side can do anything it wants.
All you need to do is add a flag to indicate that the request should be cancelled, and then change the onSuccess method to check the flag and do nothing if it is set.
You should clear the requestCancelled flag each time you make a request - or else after the first request is cancelled, you won't be able to make another one...
e.g.
boolean requestCancelled = false;
void onSuccess(...)
{
if (!requestCancelled) {
// actual response handing code
}
}
If you really want to cancel the request on the server side, it is a lot more complicated. You could do this by sending a second request - one where the fuinctionality is to cancel a request.
To make this work, the "cancel request" has to set a field somewhere the "email request" can read. The "email request" needs to check if the "cancel field" has been set.
// server side Impl
void cancelRequest()
{
// You need to implement this class and ensure it really is a singleton
// and thread safe.
RequestStatusSingleton.setCancelled(true);
}
void serverSideEmailFunc()
{
while(modeEmailAddrs && ! RequestStatusSingleton.getCancelled()) {
// get next address and send email
}
}
Obviously this is a lot of work. Have you considered:
Not having a cancel button on your GUI?
Getting the server to process emails a few at a time (i.e. client sends multiple requests until server tells the client all emails are done).
I totally understand your user. No one wants to wait for 15 seconds.
There is no standard way to "kill" the request, because there is no way to know where your server/datastore is in implementing it. Unless you deal with a process that can be put in a single transaction that can be rolled back, you will have to implement your own logic. For example, if you asked the server to save an entity, you will have to tell the server to save this entity again, but this time without the changes.
Also, think again about your use case. Why a user wants to kill the request? May be he simply wants to go to another place in the app. Then there is no need to kill the request: when the response arrives, check if the user is still in the same place patiently waiting. If not, do not execute onSuccess().