I have a backend software that needs to be able to communicate with a gecko-based web browser (and vice-versa). What is the best way to realize this? Since HTTP is rather one-way (with the exception of e.g. reverse AJAX which I consider to be quite "hacky") I am wondering how to do this.
Would creating an NPAPI-based plugin be an option? Based on the data exchanged between the browser and backend, the browser needs to manipulate the DOM of a webpage. The manipulations need to be quite dynamic and communication speed is an important requirement.
I am glad for any help pointing me in the right direction or providing useful resources that might be worth reading!
Writing browser plugins isn't quite trivial, if you can use alternatives like WebSockets (or their emulations like web-socket-js, see here and here for more details).
Only if such alternatives don't give you enough control because of special requirements should you consider writing a browser plugin.
With it you would get the full benefits of native code (high control over whatever API you choose) but also the problems that come with it:
you have to start to worry about privileges
bugs can crash the whole browser
you might have to handle behavioral differences between platforms and browsers
you have to worry about distribution on multiple platforms
...
If you need the higher level of control for some reason you could
implement the connection handling of your choice in the plugin
let the JavaScript initiate connections and send data
let the JavaScript register handlers for incoming data etc.
on incoming data call those handlers and pass them the data
To get started with NPAPI plugins see here, to support IE too you'd have to write a content extension. Finally i would advise to take a look at FireBreath that already does much of the heavy lifting for you (hides the different APIs for IE and NPAPI, gives you a higher level API, fixes for browser bugs included, ...).
Related
Let's say you set up a custom protocol handler to run an application with some startup data, right?
myapp:\\somedata
How secure is that data? I'm having trouble finding any resources talking about:
Do browsers cache this data?
Can other applications see this information get passed and how?
I've found resources talking about obvious problems, like attacking sites can abuse your protocol if they find you have one.
Otherwise, for developers looking to use their website to launch an app in this way, what do we need to be concerned about if we don't want anyone else seeing "somedata"? More specifically, how is the data accessible to attackers?
Any MDN or other official references would be much appreciated!
I am writing a remote server to control a robot with. The robot provides video and its current sensor state; the server sends control commands.
My choices for sending the frames and the control/sensor-state between the robot and the server ( 2-way ) are ZeroMQ and WebSockets.
I need:
Speed
Security
My coding partner wants to use Websockets because it's undergoing standardization, but I have 3 months of experience using ZMQ to do just what we're trying to do, so I'm fairly certain the choice doesn't matter.
However, I'd like to know if anyone can think of a compelling reason to go with one OR the other (XOR). We're not going to use ZMQ+Websockets because we don't need to.
Looking at what WebSockets are, I honestly don't think it's going to make much difference. They're simply a way to switch between speaking HTTP to the WebSocket framed message protocol down the same TCP connection. ZMQ gives you framed messages too, but you'd be using that over a network connection separate from the web browser's HTTP connection.
Latency comparisons are going to depend on just how good a run time environment the Web Browser provides. It seems to me that use of WebSockets will involve writing the client side code in Javascript and running that in the browser (the "modern" way), so that code will be at the mercy of the Web browser's Javascript engine (they're pretty good I think).
With ZMQ you may be having to write a native application for the client end (I don't know if it can be used within a web browser within Javascript - I need some education!). A native application is free of any influence from a web browser, so it might be just a shade better.
But if your real time requirement is only on the human scale (i.e. it need respond only quick enough to make a human happy), I think either will likely be sufficient. Neither can overcome propagation times across the Internet, neither can account for OS / browser delays.
The one difference is that with WebSockets it looks like you have to switch between HTTP and WebSocket protocol. So if you need to switch back to HTTP to load some web element or other, that's going to interrupt the flow of WebSocket data until you switch back again. Whether or not that is actually a problem is going to depend very much on what your client side application is doing (for example, you may very well be talking to a separate web server for web page elements, in which case you'd have two connections on the go anyway).
With ZMQ you're going to have a dedicated connection.
I've got an app that's been started on the Microsoft stack as a smart client (notionally WCF/WS enabled) with a small client app that gets deployed and the rest of the app running in our private cloud. It's only real dependency is internet connectivity, .net 4 and a windows operating system.
I am under pressure to convert over to a browser based architecture for all future development. Based on other web apps I've worked on, I'm concerned that the way that client IT organizations can control the browser, it will cause more problems down the line than what I really want to deal with.
Do you have experience making this kind of decision? What technical factors did you consider when deciding to go smart-client vs. browser? What resources were helpful in making this decision?
My app is a healthcare app targeted at healthcare providers (eg. hospitals), so everywhere I go, I have to worry about the Healthcare CIO looking over my shoulder.
Interesting. Originally I'm from C# winform and WPF Desktop programmer, and later being assigned to do web development. Haven't touch Smart Client yet but I think it should almost be the same with Native app. Based on experience, the technical things to consider are:
Multi browser support
Especially for reporting and graphic processing, without some library / plugins / framework for your component, it will be insanely hard to keep your app multibrowser. Especially in css style and less in javascript.
Client programming(javascript)
You will lose the ability to create controls and animation using C# controls. Instead you must using javascript (jquery or other library) in exchange. Javascript is not fully OOP, and intepret language (no compile error), making it harder (maybe there is some framework like coffeeScript which I haven't yet explore). In addition, it is harder to make since it will need server request / response activity in between the process, which I will describe later.
Request / Response Client-Server Architecture
This means that most process in client will need to request for the server (request for data to display, request to modify the data, etc). It also means that you lose the ability of control event, even if you use asp.net webform (it still need some tweaks for the event to work). However I assume you already used the WCF so this kind of architecture must be that hard.
Security
Don't keep important information such as password, etc in client (hidden field, javascript variable, etc). The concept should be the same with multitenant client, however in browser, user has free access to debug your webpage.
Concurrent and Multithreading
In browser, it is easier for multitab page and concurrent process will be very highly to occur. Your code must able to handle the multi threading for client side. For server side, you can still use your WCF to handle concurrencies.
My 2 cents.
Obviously the web application has its own challenges. I hope this link can help you in some aspects: http://msdn.microsoft.com/en-us/library/ee658099.aspx
Along with those you need to focus on non-function requirements like extensibility and scalability etc. too.
gud day!.
i am to develop a system that would simply list all URL accessed in a browser with its response time.
my probtion is alem is this applica standalone program(not a plug-in to a certain browser) written in c++. every time a user browse, the program then performs certain method.
so it is like, my program would listen to the browsers events. i dont know how to create an EVEN SINK implemetation for the above mention event in web browsers like Internet explorer, mozilla firefox and google chrome.
any suggestion, advise or idea i cant get from you for me to be able to start the development. any areas i need to focus in studying.
thanks alot for your time! hope for your response!:)
best regards!
The easiest way to achieve what you need is intercepting network traffic and extracting URLs from HTTP packets.
You can do this in many ways, e.g.:
using WinPCAP/libPCAP libarary
modifying LSP stack
intercepting winsock functions calls
If you're on the Windows platform, I think your best shot is using the MSAA interface, which is supported by all three browsers.
Documentation:
MSDN Overview and C++ API
Firefox statement of support for MSAA
Chrome
You could take a lower-level approach (such as an LSP), but they're much harder to debug.
I'm mostly looking for setup advise and pointers on how to go about going about this. I'll explain in as much detail as I can think and also note possible approaches that may be plausible.
The aim of this is to create a real time browser game, the best method that I have found for my needs would to use "long polling" with ajax, which will basically setup a request with the server that will "hang there" til the server has something to send it, then re-establish the connection upon receipt for more data. For my purposes this will handle a chat system aswell as character movement, IE: if a player enters the same area the clients there will recieve a response to inform them and thus update the browser client to show this.
The above is relatively easy to implement and I have already made a test-case for it, however I want to improve on it, on the server side it runs a loop for X amount of time before it'll auto timeout and send back and empty string, so another connection can be made, this is to prevent infinite loops and use up resources in cases where it shouldn't. Instead of looking up the database on each loop cycle (would be expensive I believe) for messages that need sending to the client, I use flatfiles, if a file has a modified timestamp greater than the last message sent to the client, then there is something new to send. However I believe this would also be expensive (not as much as using a mysql database though?) when done a couple of times per second.
My thought process on this was to have a C++ program (for speed) constantly running, and use that for very fast lookups in memory for new messages and so fourth, this would also give me the added bonus of being able to have bots within the game that the server can control for a more real-time feel/approach, however I have no clue if this is even possible and my searches on google have been fruitless.
The approach I would most love to be able to do, is to continue to use PHP to do the rendering and control of the page etc, and have the ajax requests go to the C++ application (that will always be running) that can handle all the real-time aspects.
CGI defeats the purpose of the above approach, as it creates a new instance of the application on each request, which is both slow and exactly what I do not want, I have php for that and don't want to switch one perfectally running language for another that would be better suited, PHP however (to my knowledge) can't store things in memory (ram) and so fourth.
Another approach that I have thought about was to use php sockets to connect into the C++ application, though I have no idea how feasible this may be. The C++ application only basically will need to control bots (AI) and the chat system messages.. I have absolutely no idea how to go about handling bots via PHP.
I hope this fully explains what my intentions and goals are, so if anyone has any pointers or advise then please reply and help me out, it would be very much appreciated. If you need any extra information (for if I didn't cover something or something very well) then I'll be happy to attempt to better explain.
How fast do the reactions need to be? For anything approaching real-time action games, AJAX/Comet is going to be much too slow. The overhead is also really depressing.
The way forward for that kind of thing will probably be WebSocket, with a custom server on the backend. But I don't think that means you need to resort to C[++] for this; the bottleneck is most likely going to be the network and not server processor power.
I'm using a Python SocketServer with a trivial message replication system — all the game logic in my case is on the client-side, with some complicated JavaScript maintaining a consistent game world in the face of lag — but even for a more complex server-side I think a scripting language will probably be just fine.
WebSocket isn't ready yet; there are no mainstream browser implementations. In the meantime I'm using a Flash Socket backup that emulates the WebSocket interface. Flash Sockets have their own problems in that they fail to negotiate proxies, but they are fast and hopefully the need for them will diminish as WebSocket arrives properly.
Reading your post sets alarm bells ringing.
How familiar are you with multi-threaded code? With C++? If the answer is "not very", then I fear you might be biting off a quite a large chunk. Why not take advantage of some existing (tried and tested) COMET server implementations rather than this barebones approach? Whatever application you have in mind, it should be quite separate from the comms implementation.
As someone who has implemented a such a server, I can tell you that it will take many design iterations and a helluva long time to get right. Testing such a product realisticly is also a very tricky process.