I'm looking at this: https://mtgox.com/api/2/stream/list_public?pretty And I only see one: "trade.BTC": "dbf1dee9-4f2e-4a08-8cb7-748919a71b21"
When trying to connect to it, I'm getting very odd trade data, which, when compared to what I see on BitcoinWisdom doesn't really correlate. Where do I find an actual channel for BTC/USD trade and also what are the addresses for other currencies trades?
Its d5f06780-30a8-4a48-a2f8-7ed181b4a13f
Try the following in the PubNub dev console to see the messages on this channel
https://www.pubnub.com/console?sub=sub-c-50d56e1e-2fd9-11e3-a041-02ee2ddab7fe&pub=demo&channel=d5f06780-30a8-4a48-a2f8-7ed181b4a13f&origin=pubsub.pubnub.com&ssl=true
You can also check http://rtbitcoin.co/ (PubNub Bitcoin Exchange solution kit) for more info
Also check a related stackoverflow post here
Related
So I managed to connect to the websocket with my API token and I do get notifications. For incoming calls, I do get a push with all info like so:
{"type":"push","targets":["stream"],"push":{"type":"mirror","source_device_iden":"XXXXXXX","source_user_iden":"ujC7S24sQxw","client_version":206,"dismissible":true,"title":"5555551212","body":"Incoming call","application_name":"Pushbullet","package_name":"com.pushbullet.android","notification_id":"6","icon"
"Big value here"}}
So I can see that call came from 555-1212 (I changed number for privacy) and it all makes sense. However, for SMSs, all I get is a notification that SMS changed. No body field so I can't see where it came from and what the message is. All it says is sms_changed for type:
{"type":"push","targets":["stream"],"push":{"type":"sms_changed","source_device_iden":"XXXXXXXXX"}}
What am I doing wrong? I would like to get the SMS message and sender info so that I can publish it. Any and all help will be greatly appreciated.
This is not publicly documented yet and we might be changing the implementation in the near future so I'm hesitant to make it public. Also I don't know the specifics of the current implementation.
You can view how it works right now by using www.pushbullet.com and looking at the network traffic (in chrome inspector) when you do SMS stuff on the website.
I just checked Amazon SNS service (beta) to see how it works, but I became really confuse about the technology behind Notification Service. I am not looking for specific IOS or Objective-C answer, also I know it may use an open TCP connection (with an open port or long pooling), but I am looking for some information regarding the technology behind it or any possible protocols.
Please Let me know if you have any short reference for that.
SNS is about publishing notifications (pubsub).
Once you have a topic, you can create subscriptions. A subscription is roughly made by a protocol and an identifier (email, url).
Once set, topics will broadcast the messages to its subscribers
One of those, however, is SQS, which allows Long Polling (up to 60s).
I'm using a TK102 GPS localizer. Along with it, I got only simple end-user docs. No API, dev specs or similar for writing code that will use this localizer.
I was told that it uses UDP. So I wrote a simple PHP listener. But either localizer is not using UDP or something is wrong in communication between it and server. Listener works fine (gets UDP packets from other clients) and localizer is sending something (I'm being charge by GSM operator for GPRS transmission), but the data it sends, doesn't reach server.
I asked about server or networking issues on Unix/Linux and SuperUser. Here I would only ask, if someone knows any API/dev-specs for this localizer, so I can check, if it really uses UDP or if I haven't made any other error (in configuration for example).
The localizer and its clones
We're talking about Xexun TK102 Tracker here. The original one, because there are many clones under other companies from China, selling similar GPS localizer, with the same cover and logo, but with:
less performance electronics on-board (for example -- able to report location once per 20 or 30 seconds, not once per 5 seconds like in original one),
the ones that are sending lesser information (lack of direction/bearing, altitude, number of satelites used for location fix and many more),
units using different format of data or non-standard transmission protocol for sending it (for example, cheaper units are unable to use UDP protocol and are transmiting data through TCP protocol, using packets that not always follows standards or definictions.
Coban and Kintech are only two of many clones sold on eBay and in e-shops, claiming to be original Xexun trackers.
On the other hand, original Xexun and some clones (like Coban for example) are harder to control from own script, because they require a correct answer from the server, where data is sent over GPRS. If unit does not receive such reply, it breaks connection. The cheapes unit does not have this checking and will always sent location data to specified IP address over provided port.
Product description
Here is product description of original Xexun localizer (and here is a clone under Kintech name).
Possible buyer must be very careful (and should secure return policy, for which buying directly in China is not recommended) as there are many reports about sellers claiming to sell original Xexun device and sending a clone actually.
Though this device is five years old, it is still sold at many places (including eBay), but even at theses sources it is very hard to get anything worth for developers, except some simple, very basic user guide.
I have confirmed information (from two different sources) that there is no official API available for this device. The only option is to Google around, ask other users or use forums (see below).
If you own original Xexun localizer, you may try to contact company international departament and ask their technicians to include some changes to device source code and to send you updated firmware, with your changes - wow! That was confirmed by company itself.
Forum
I found a perfect forum for TK102 device, with a lot of questions and answers:
here is a general forum on TK102 device (kept alive for 4,5 year with 171 pages and 2000+ posts!),
here you'll find more specific topic on receiving data from this localizer,
this forum is also about TK102 unit, but it is entirely in French.
There are many other devices dissussed and in general, this is the biggest forum in the world, with topics for localizers and simillar information.
GPRS Protocol Specs
In general, any TK102 related devices is opening a socket for a direct TCP transmission (original one can be switched to use UDP protocol). Data is being transsmited over port specified by user, in configuration and using GPRS only (requires SIM card with enabled GPRS, there is no way to use WiFi).
Sending frequency, format and amount of data being send, entirely depends on kind of device is being used -- it is more extensive and more configurable in original one than in clones.
Using FileDropper I shared GPRS Protocol Specification for TK102 Geolocalizer. It contains basic information on how to setup TK102 (and possible all its clones) to send location over GPRS. And what sort of data you should except to receive from in, on server side. This could be useful for someone.
BTW: If links goes dead, contact me for a reupload or sending it over e-mail
Correct server response problem
Make sure, if you're using correct data transmission protocol! Many (really many) cheap clones uses TCP, while only original TK102 allows switching to UDP. This is convenient, because you need really basic server configuration to handle TCP connections, while you have to use specific server-side software (like node.js) or specific configuration (open to certain ports) to handle UDP. But the key thing is to determine correct protocol, as listening to TCP data, while your localizer sends UDP, will most certainly fail.
Take into consideration, that many TK102 clones requires a correct response from the server after each data, it send. It breaks connection after sending some welcome garbage UDP packet, as it does not receive response, it waits for.
It is quite hard (quite impossible?) to find any guide to many of these clones, on what kind of responses server should sent. This often leads into situation of developer being unable to estabilish two-way communication between server and localizer. Many localizers are sold to be used only via SMS communication or throughs paid services that had signed and agreement with producer and received protocol specification that contains valid responses server should generate for particular TK102 clone.
Double check, if this is not source of problem, if you can't communiacte with your localizer from your app.
You can check some models protocol specs here:
http://www.traccar.org/docs/protocol.jsp
I am currently interested in seeing what channels are subscribed to in a Redis pub/sub application I have. When a client connects to our server, we register them to a channel that looks like:
user:user_id
The reason for this is I want to be able to see who's "online". I currently blindly fire off messages to a channel without knowing if a client is online since it's not critical that they receive these types of messages.
In an effort to make my application smarter, I'd like to be able to discover if a client is online or not using the pub/sub API, and if they are offline, cache their messages to a separate redis queue which I can push to them when they get back online.
This does not have to be 100% accurate, but the more accurate it is, the better. I'm assuming a generic key does not get created when a channel gets subscribed to, so I cannot do something as trivial as:
redis-cli keys user* to find all online users.
The other strategy I've thought of is just maintaining my own Redis Set whenever a user published or removes themselves from a channel (which the client automatically handles when they hop online and close the app). That would be an additional layer of complexity that I need to manage and I'm hoping there is a more trivial approach with the data that's already available.
As of Redis 2.8 you can do:
PUBSUB CHANNELS [pattern]
The PUBSUB CHANNELS command has O(N) complexity, where N is the number of active channels.
So in your case:
redis-cli PUBSUB CHANNELS user*
would give you want you want.
There is currently no command for showing what channels "exist" by way of being subscribed to, but there is and "approved" issue and a pull request that implements this.
https://github.com/antirez/redis/issues/221
https://github.com/antirez/redis/pull/412
Due to the nature of this call, it is not something that can scale, and is thus a "DEBUG" command.
There are a few other ways to solve your problem, however.
If you have reason to believe that a channel may be subscribed to, you can send it a message and look at the result. The result is the number of subscribers that got the message. If you got 0, you know that they're not there.
Assuming that your user_ids are incremental, you might be interested in using SETBIT to set a 1 or 0 to a user's offset bit to track presence. You can then do cool things like the new BITCOUNT to see how many users are online, and GETBIT to determine if a specific user is online.
The way I have solved your problem more specifically in the past is by signaling a subscription manager that I have subscribed to a channel. The manager then "pings" the channel by sending a blank message to confirm that there is a subscriber, and occasionally pings the channel thereafter to determine if the user is still online. Not ideal, but better than using DEBUG CHANNELS in production.
From version 2.8.0 redis has a pubsub command that would help in this case:
http://redis.io/commands/pubsub
Remark: currently the state of 2.8.0 is not stable yet (RC2)
I am unaware of any specific way to query what channels are being subscribed to, and you are correct that there isn't any key created when this happens. Also, I wouldn't use the KEYS command in production anyway, as it's really a debugging command.
You have the right idea about using a set to add the user when they're online, and then query this with SISMEMBER <set> <user_id> to determine if the messages should be sent to them or added to a Redis list for processing once they do come online.
You will need to figure out when a user logs off so you can remove them from the list of online users, but I don't know enough about your system to know exactly how you would go about that.
If the connected clients have the ability to send a message back to inform the server that the message(s) were consumed, you could use this to keep track of which messages should be stored for later retrieval.
Cheers,
Mike
* PUBSUB NUMSUB [channel-1 ... channel-N]
Returns the number of subscribers (not counting clients subscribed to patterns) for the specified channels.
https://redis.io/commands/pubsub
hi
I cannot see any explanation of the implementation of the collapse_key.
I think i understand what it does but not how it do it!
Android Cloud to Device Messaging Framework
I have a C2DM framework set up and sending 4 types of messages to many phones.
String messages very basic looks kind of like this:
type:name:uuid
type:name:uuid:number
type:uuid:id
If the phone is off many of this can get piled up waiting for phone on-line.
as far as i can tell my system works but what will the collapse_key do for me here?
addEncodedParameter(sb, "collapse_key", "no_ide_what_to_put_here");
You mentioned retrying the same message 3 times and using the same key value. It doesn't really have to be the same message. If you've got a message that indicates the current price of a stock, for instance, and you really only care about the latest price, then you could send different messages with the same key. When the device comes back online, it only gets the latest price quote message.
This may have been what you were saying already, but wanted to make it clear it's not only for "retrying sending same message".
I found this text: “collapse key” used for overriding old messages with the same key on the Google C2DM servers" I think if im retrying sending same message 3 times I must use same key value right. Google cloud server will send the latest msg with the same key value
...but be aware of the following (from http://code.google.com/intl/sv-SE/android/c2dm/):
"Note that since there is no guarantee of the order in which messages get sent, the "last" message may not actually be the last message sent by the application server."
But maybe this is not an issue if you don't generate a lot of messages.