I am wondering if there is a good way of making automated system testing for a Chromecast receiver application?
If you open the application URL in a Chrome browser, the cast_receiver library cannot find the websocket connection on:
ws://localhost:8008/v2/ipc
Since this handles the communication between the app and the Chromecast hardware, I am thinking of something like a Node.js websocket server that can talk to the chromecast receiver app. Is there such a system, or do anyone know if there are plans of google releasing something for this kind of testing?
Also, would there be other problems related to the difference between the chromecast browser and chrome browser? As I understand, the chromecast browser is just a subset of chrome, which makes me think it should work.
No, there is no easy way to do this.
DISCLAIMER: I haven't tried any of what I'm about to suggest. It's also probably a terribly idea as Google could change the protocol any time and in any fashion they desire since it isn't a public thing.
BIG DISCLAIMER: You may be in violation of the ToS by doing this as Section 3.2 (Developer Policies) states that you "may not ... develop a standalone technology ... any functionality of any Google Cast Receiver". Possibly, you'd be making a standalone piece of technology that replicated the IPC functionality. But I don't know. I'm not a lawyer.
If you want to go and do this, I'd suggest making a copy of the Google Cast Receiver SDK (www.gstatic.com/cast/sdk/libs/receiver/2.0.0/cast_receiver.js as of April 28, 2015) and altering it so that it logs out the messages that are being sent and received.
Luckily, it appears that we have logging messages to help us find the relevant code.
The receiving method has the string "Received message". I would guess that "a.message" is what is being received.
The sending method has the string "IPC message sent". I would guess that "a" is what is being sent.
Once you've instrumented your copy of the code, you need to publish it somewhere that your receiver app can see it and then you need to edit your receiver app to point to your new and improved SDK. Please please please make sure that you do this on a non-published app for testing purposes only.
Once that is done, you need to find some way to get your messages out of the code and into something that you can access. You have a few options.
Fiddle around with the code more and figure out how to get the Chromecast to log out the data you want;
Store the information in an array and read it using the debugger;
Open your own socket (or websocket) and send that data to a server that you control.
From here, you can run your app, interact with it, and then have a complete record of the IPC messages that were sent and received. Armed with this, you can create your own Fake-IPC server that listens for specific messages and spits out the stuff that is in your log.
Related
In database some entity is getting updated by some backend process. We want to show this updated value to the user not real-time but as fast as possible on website.
Problems we are facing with these approaches.
Polling :- As we know that there are better techniques then polling like SSE, WebSockets.
SSE :- In SSE the connection open for long time(I search on internet and found that it uses long polling). Which might cause problem when user increases.
WebSockets :- As we need only one way communication(from server to client), SSE is better then this.
Our Solution
We check database on every request of user and update the value.(It is not very good as it will depend upon user next request)
Is it good approach or is there any better way to do this or Am I missing something about SSE(misunderstood something).
Is it fine to use SignalR instead of this all?(is there any long connection issue in it or not?)
Thanks.
It's just up to your requirements what you should use.
Options:
You clients need only the update information, in the case they make a request -> Go your way
If you need a solution with different client types like (Webclient, Winformclient, Androidclient,....) and you have for example different browser types which you should support. Not all browsers support all mechanisme... SignalR was designed to choose automatically the right transport mechanisme according to the mechanisme which a clients supports --> SignalR is an option. (Read more details here: https://www.asp.net/signalr) Has also options that your connection keeps alive.
There are also alternatives like https://pusher.com/ (For short this is only a queue where you can send messages, and also subscribe for messages) But these services are only free until for example some data volume.
You can use event based communication. When ever there is a change(event) in the backend/database, server should send a message to clients.
Your app should register to respective events and refresh the UI when ever there is an update.
We used Socket IO for this usecase, in our apps and it worked well.
Here is the website https://socket.io/
Has anyone got an elegant way to resolve an ordered delivery send port (with stop sending subsequent messages ticked) that has suspended (non-resumeable)?
Please let me know how you handle it. Do you use any tools, or created any custom tools.
Not a good way out of the box. We have developed some utility to save these messages in case required using BizTalk Explorer OM, however BizTalk Explorer OM also has a limitation of saving only 50 messages in one single service instance. So your best bet is to make sure you have a way to replay those messages from outside by keeping a copy of message.
Basicly, I'm trying to read a game's chat and catch actions from the user.
Here is the image which I will explain the situation with :
1: I took a message in the chat
2: I tryed to find it in the game's memory with Cheat-Engine
3: By examining every addresses where it was found, I ended up to this one, which contains the chat formated with what seems to be html..
That part is only the bottom part of the chat. (I see the rest of it if I scroll up)
So, I asked myself how could I read game variable to interact with the game.
Another thing I'm trying to achieve is to catch the user's actions so I can display some information in a winform.
I've just read about packet sniffing, it seems interesting for what I'm trying to do.
I tryed to read packets going in and out of this app with WireShark. Every action in game was sending a few packets, but I couldn't read them as they were just a bunch of weird characters. I tryed to decrypt them using a few methods I got on WireShark's forum without success. I was asking myself, even if I could see them in Wireshark, how am I gonna do that programmatically..
There is certainly a good way to do this, as we often see bots in this game.
Considering the number of bots playing "in team", I'm pretty sure they do not use clicks, but they run something in background that sends requests.
How do you make such a bot that fight, talk, interact with players automatically?
This game is Dofus, powered by Adobe Air.
I usually program with c++ and c#, but I was wondering what's the best way to do this.
I need a kick in the right direction!
Maybe trying a tcp/ip listner control (or use tcplistner class in c#) in your c# project with the appropriate port to catch requests (& responses). Information sended could be compressed so you may want to try some standard algo.
Did you try reverse engineer the AIR app ?
I have this weird requirement to access scanner, barcode reader, camera etc. from an asp.net application. Since these are local resources, i know its not possible to do that. I was wondering if there is some other solution to this problem.
I was thinking of creating an windows service that will run on local system and will open a port and listen to it and does the required job. I was wondering if there is a way to send some kind of message to the local port from an asp.net page using JS or some other library or activex.
If you have totally different solution, i am all ears.
We solved an analogous problem (ticket printer attached to serial port) by creating a tiny app (TCL/TK original, as it runs nicely on Win/Mac/Lin, but C#/.NET now since mono grew up), that
takes the user/password
creates the session with a web request.
opens the browser,
giving the session token in the URL as an anchor (http[s]://foo.bar/baz?x=y#sessiontoken)
This way it is never transmitted over the wire, but is available to the JS code in the client.
After the helper app has started the browser, it uses long polling and the session token (known to the browser and the helper app) to communicate with the webserver - as a client-sided app it can communicate with the peripherial quite naturally.
100's of 1000's of tickets printed this way ...
Edit:
Yes, I know this gets longer and longer, but I need (and was asked to) to elaborate.
If you want to avoid going the ActiveX/Silverlight/whatever route, which I strongly suggest, you need 4 players:
Webserver
Browser
Helper application ("Agent")
Device (Ticket printer, Barcode scanner, whatever)
Your basic problem is, that 1. needs to talk to 4., but can't. So you choose two parallell paths: Communication meant for the user is exchanged between server and browser, while communication meant for the device is exchanged between server and agent, the latter relaying it to the device (and ofcourse the other way round).
The agent is a quite simple application, that talks to the device via the OS facilities (how exactly this is done ofcourse depends on the device), and talks to the webserver via HTTP requests.
Depending, on which direction of information flow you need:
To facilitate information flow from the device to the server, simply
have activity on the device trigger a webrequest. (Input device, e.g. barcode scanner)
To facilitate information flow from the server to the devide, use long polling. (Output device, e.g. ticket printer)
For both directions do both (Server-triggered input device, e.g. camera)
Now the remaining problem is, how to correlate a human action in the browser with a device action - in short: How can the server send the ticket you chose in your browser to your ticket printer, not to whatever printer long-polls next.
To solve this, using the session ID is a natural fit - but it requires to have the browser and the agent both know the same session ID. For this to happen, you need to communicate it from one to the other. Since you can't communicate it from the browser to the agent (or this discussion would be moot), you need to communicate it the other way round - and the anchor in the URL is the vehicle to achieve this. You do the following:
User starts the agent (not the browser!) and enters his credentials
Agent calls sends a web request for a login to the server, and gets back a session token (please use some basic cryptography or go for HTTPS)
Agent then starts the browser (e.g. by executing cmd.exe /c start "http[s]://domain.tld/start.aspx?x=y#sessiontoken")
Since the session token is an anchor, it will not be sent over the wire, but will be available to the browser-sided code ... Bingo!
Now the two parallell paths are open: The browser for the human requests, knowing the session token, and the agent now going into the modes described above,
You can use ActiveX to do that or, maybe Silverlight (or Flash) which provide limited support for (at least in my experience Camera, Microphone and Scanner).
But, given a previously experience with something related to what you're trying to do I'll suggest you to better buy an SDK prebuilt.
Imaging:
http://www.viscomsoft.com/
Barcode:
http://www.tec-it.com/software/barcode-software/tbarcode/barcode-generator/Default.aspx
I'm sure Wave doesn't poll the server every millisecond to find out if the other user has typed something... so how can I see what the other person is typing as they type? And without hogging the bandwidth.
Persistent HTTP, Comet
Keep your HTTP connection alive and send characters as they are typed
*Edit in 2014: also, take a look at WebSocket and HTTP/1.1 Upgrade header. Browsers started implementing this around 2010, so I'm adding this to original answer.
They probably use Web Sockets, aka server-sent events: http://www.w3.org/TR/websockets The underlying protocol can be found (as a draft) at the IETF.
Update: it doesn't seem WebSockets has any implementation yet; and a video from Google I/O (go to 11:00) talks about a long lived HTTP GET request.
Server Push in GWT
Server push is the Wait, Respond, Close, Re-Open paradigm:
Wait: When the GWT code makes a call
to your server for some data that you
don't have yet, freeze (wait)
Respond: Once the requested data is
available, respond with it
Close: Then, close the connection.
Re-Open: Once your GWT code receives the response, immediately open up a new connection to query for the next event.
See Video Google Wave: Powered by GWT around at minute 55 (near the end)
Q: How you implement the persistent Connections, the long living http connections
A: Future Plan: HTML5 Web Sockets. Longer term. That's what we use at the moment.
Q: Is there a platform or library for this we can download and play with?
A: Not sure. Don't think so
P.S.: That's what he said. To me it did not make much sense ("future plans" vs "using at the moment"). Any native english speaker might want to verify if I transcribed it correctly?
Pure speculation but could it be using the Server Side DOM events from the HTML 5 spec?
the entire reason for WebSockets is to have the browser keep a bi-directional socket open to a server so that real time communications can be used. When someone types on the other end, in a wave client, it triggers an event that is sent to the server and the server in turn looks to see who should also receive the event and pass them the event, in this case the typed letter.
WebSocket and Comet are different.
Granville
Probably comet for now websocket in the future. Because it works in Firefox 3.5 and from what I've read the websocket is only available in the nightly builds of FF... I could be wrong though... as it appears to not work in IE at all.
I spent some time reverse-engineering the Google Wave client code (shameless plug for http://antimatter15.com/misc/read/ which is a read-only public client for google wave for all public waves without need of robots or gadgets which was a lot more useful a month ago when Google didn't launch the upgrades).
Anyway, Google uses the GWT framework with certain aspects of the Google Closure library (which is actually open source and documented) and they use the goog.net.BrowserChannel library, which from the comments is also used for chat functionality within gmail.
http://closure-library.googlecode.com/svn/docs/closure_goog_net_browserchannel.js.html
I would assume that they use ajax requests. Do an XMLHttpRequest, which is asynchronous, and when the server has something to send your browser the javascript callback that was registered gets the data and does whatever with it. So basically the browser requests the next event, handles it, repeats indefinitely.