Is the following possible? There are 2 persons working on 2 different computers. Both are connected to the Internet. These users can communicate with each other using a JavaScript program run in a browser.
I do not want to use a server. I want to use a P2P approach and I am wandering if it is possible to do it with the JavaScript?
No.
The same origin policy prevents JavaScript (in a webpage) from opening a connection to a host other than the one on which the page was served from.
You will need to use a server in any case. Even if you could specify an IP address and tweak JavaScript into establishing a connection to a computer using AJAX / JSON / JSONP, the other computer would have to have some serving capabilities to answer the call, something which neither your browser nor JavaScript are equipped to handle.
For direct computer-to-computer communication, you will need to delve into serious client side programming, for example using Java, C++/C#, the .NET platform or something similar.
No this is a violation of the same origin policy.
You cannot do that with pure javascript without using the server, I think. Javascript can communicate with network only with ajax requests so the other computer would have to run http server.
The opera unite service allows you to do this. Of course this is limited to Opera browsers only.
Take a look here for a fantastic introduction to the system
Maybe consider using Java instead? You still need a server though so clients can find eachother.
A server in the middle is definitely required. Absolutely no way around that.
I am curious what you would want to do this for though?
Related
You know, a web server. Right now my Socket.IO server loads from a BATCH file that is a JavaScript file. Can you use node and make the socket.io server load from a web browser. Like a web-server utility tool or something of the sort.
That's explicitly not possible due to the design of WebSockets. It starts as a special HTTP request that, after the handshaking, drops the HTTP protocol and strips it down into the WebSocket protocol -- a nearly bare protocol similar to (but slightly more managed than) raw TCP. Because a web browser specifically cannot handle HTTP requests, it could never initiate the socket as a server.
This was done specifically so it wouldn't be possible to write a drive-by botnet website to use scores of users' computers for DDOS attacks without their knowing, amongst other security concerns.
So it wouldn't surprise me if Flash supported that kind of behavior. ;) (I know Java can, but who enables Java applets?)
I'd say you Can. Not that I can think of a good use case.
You would need to put the startup code somewhere where the web server could run it and you would need to get the web server to return some information to the browser to allow it to then connect. You would also have to insert the socket.io code into the browser after the socket server had started.
So I Think that it would indeed be possible but rather complex for little gain. I suppose one possible use case would be to restart a socket server after failure. Actually I'd do that a slightly different way, probably by calling an external script from Node.
fortunatly the answer is no. if you mean by load / launched , NO. but you can create a script on a server that launch another server once a url is requested by a a client.
I'm looking at options to connect directly--without a web server or middleware--to a PostgreSQL server using JavaScript from a web browser client. On github, I found three projects:
node_postgres
node-postgres
postgres-js
They all appear to be in early but at least somewhat active development.
Do they all do roughly the same thing? Is what they do even what I'm looking for? Does anyone have experience with any of them that could recommend one over the others?
node-postgres was inspired by postgres-js and does roughly the same thing.
However, they both seem to be their own sort of middleware, because they require node.js, which is a server-side JavaScript implementation of a web server. So they would cut out a layer, but still not be the same thing as connecting directly to the PostgreSQL server.
There might be a way to combine the code in them with some HTML5 socket examples, though, to make connections directly from a web browser client.
If you are interested in CLIENT side JavaScript, as the OP's question implied, but you don't insist on owning the server, there is a commercial service that can help you.
The Rdbhost service makes PostgreSQL servers accessible from client-side JavaScript. There is a security system to prevent unauthorized queries, using a server-side white-list and an automated white-list populating system.
It uses plain old AJAX style http requests, provides a jQuery extension to facilitate the querying.
See https://www.rdbhost.com .
There is no secure solution today. One of possible solutions would be htsql:
http://htsql.org/
However there you use web addresses to query, even with https your queries will be plain text!
You should/could use a small webserver to handle requests. Alternativelly you can write an app, or use a local postgres server to handle the connection (in this case you still will need some kind of webserver).
The problem is very simple: your webbrowsers are limited in protocols to talk to the web, and postgres is not on this list. In fact you should not try to overcome this issue, using a server-client architecture is a very good solution. Format your request with JS to make it as small as possible, and let your web-server scripts interpret it into functional sql requests. The answer can be parsed into shorter response, then a sql data transfer, and you just need to interpret it on your side. Since you will create interperers on all sides, you will achieve a higher abstraction then in case of direct db connection, and thus independency towards the backend engines you use.
I have to program websites, but I rather don't like the static HTML nature. I prefer more of a client-server architecture.
Now I've figured, that with XMLhttp, you can basically dynamically update your page and send/request for information/action to/from a server. So this would basically cover the client area.
But to complete a client-server architecture, it is necessary for the server to send/request information, too, without being queried.
Is there any way, for example for a chat server, to send back a received message to all clients (the clients use a web browser) without that the clients have to query in a fixed interval? I want to implement that one can see while you type something in.
There are several different ways to accomplish this. Some of them are already answered here, but I wanted to include a few more as well as my thoughts on them.
1. Polling
Frequent requests are made to the server to check for new info. This is the worst way to do this, but probably the easiest. If your site will have a low number of users, it might be worth doing it this way.
This can be accomplished by using setInterval(myFunction, n) in javascript to send XMLHttpRequests to the server every n milliseconds. Then, on the server, you respond to this with your new info, when you have it, or some message that implies no new info.
2. Long Polling
When the page is loaded, it makes a request to the server for new info. The server holds the connection open until there is something to send back. This method reduces the amount of network traffic used, but increases the resources used on the server. You can use this for a small number of users, but it doesn't scale very well.
The easiest way to do this is to have the page that handles the AJAX request simply wait for new information to be available, then respond. This can tie up a lot connections on your server. So, use with care.
3. COMET
COMET is basically long polling, but the server is setup properly for it. It knows that these connections aren't "real" and it uses less resources to handle them. This is a great solution for this problem, but it requires that the server is explicitly setup for this purpose. There are COMET servers and COMET addins for other popular servers, but it will require some setup and sometimes some money.
Implementing this on .NET isn't the easiest thing in the world. You can pay for solutions, try to find someone else's code that does something similar, or try to write it yourself. I've not found any decent free solutions for this. If someone else has, please comment.
4. RIA
Another solution would be to include Flash, Silverlight, or Java Applet on your page. People often do this by using a 1x1 object so that they can use Flash or Silverlight to talk to the server. If you don't mind adding the dependency, this is a decent solution. If you already know Silverlight or Flash, it could be relatively simple to implement.
You can find tutorials on the internet for each of these options.
5. Web Sockets
If you are on the cutting edge, you can look into Web Sockets. It's only available in the latest builds of modern browsers. It was part of HTML5, but it might be its own spec now. Regardless, it means that older browsers won't be able to handle it. But, if you don't mind limiting yourself to the latest of browsers, you can use this amazing feature.
I believe that Chromium is the only browser that currently supports it. However, there is work being done to implement this in Firefox and WebKit.
I'll spare you the controversy and simply say that this does exactly what you want it to. The Abstract of the spec says it all.
This specification defines an API that enables Web pages to use the Web Sockets protocol for two-way communication with a remote host.
Special Mention
If you are interested in the world of Node JS, you can't go wrong with Socket IO. It will implement the best of whichever technology is available to the browser.
Conclusion
The best option is Socket.IO on Node JS. However, for an ASP.Net solution, go for COMET or Web Sockets, if you can. Otherwise, using Flash/Silverlight isn't terrible. Finally, polling and long polling should be last resorts. You could always support one of these, then fall back to another if there isn't support for it in the client's browser.
Yes, you can use COMET.
The client has to tell the server when the client-user begins typing. You've got a couple options here.
Frequent requests from the server for the latest activity. This would be taking place for each user involved in the chat. The same request could be used to send user-specific activity to the server as well: "Jonathan is typing..."
Long-polling. This essentially requests information from the server, and the server keeps the connection opened until it has something to send back. So your requests are minimized, but your connections stay opened longer.
Depending on your traffic, type of data being transmitted, server-environment, and many other factors, one of these options may shine more than the other.
You can use Silverlight for push notifications. Look at PollingDuplexHttpBinding. Since you are using ASP.Net MVC, adding Silverlight will be easy.
Look at this page for more information.
Based upon the REST architecture the html system is based upon, the servers role is to simply act as a resource for the client to pull from. I am generalizing but there are tools to implement this type of action on the client side, rather than on the server side.
You are better off writing/using a library that can request updates from the server periodically. You can encapsulate these types of requests in a javascript object that can fire events. This way your client side script can act like it's getting notified from the server. Review some common stuff with COMET you can probably find some tools to help you client side code.
HTML 5 has some tentative attempts at this type of functionality, but if you want your app to work on older browsers, your better off using more stable methods, like AJAX requested updates.
I am working on a project right now that requires some javascript for the proper functionality we are looking for. The problem we are running into is that the clients of this web-based app can only access the site through a proxy server (due to strict policies). This proxy server is stripping the javascript from the page and we are unable to replicate the exact proxy setting to determine a solution. Has anyone ran into this problem before and found a solution?
If there's a fixed set of client machines, and you can go for Firefox only, you might be able to do something using a Firefox extension or a bookmarklet that fetches the Javascript some other way that the proxy doesn't recognize (e.g. as base64 encoded data). It would however certainly require a load of work, and you may have to program the extension yourself... Probably cheaper to buy a new Proxy.
Some of our customers had these problems and we told them to access our app via HTTPS and that cleared the issue since most proxy won't filter secured traffic.
I just learned about the AJAX Push Engine but it runs on Linux/Apache which is not an option for me.
http://www.ape-project.org/
Currently with AJAX to keep a page current I have to poll the server frequently which is not great for a high traffic site. The option to push data to the client only when necessary is a great option, but natively JavaScript does not support sockets, AFAIK. One trick I read about, but the site is now gone, is to use a Flash module to handle socket communications and relay message to JavaScript.
The trouble with researching this approach is that "JavaScript push" as keywords come up with the push function for arrays instead of the context I want.
How could establish a persistent connection with the server to do push communications in the browser? Do I need Flash/ActionScript or is there another option that would work with all of the currently active browsers? (IE6/7/8, FF3, Safari, Chrome)
When it comes to the server I also need to work out the complications due to Origin policy as well as port security. I appreciate anything you can point out that will explain the available options.
What you want is COMET, or I would also look up long polling.
I asked a similar question.
The Direct Web Remoting (DWR) library supports Reverse Ajax, which sounds like what you are looking for. It supports Comet (along with Polling and PiggyBack). More info on their website: http://directwebremoting.org/dwr/index.html
This is interesting stuff, but I did not read anything about scalability issues on these Wiki pages. What does a web server do if you have 10,000 open long-polling connections?
Also, for those not familiar with the underlying concepts, it is important to understand that pushing data from the server to the client in an ad-hoc fashion is impossible and will always be. Even if the HTTP protocol supported this, the network would not, particularly if there is a NAT firewall involved.
So any solutions that claim to offer server push communication must rely on connections that are initiated by the client, kept open, and will eventually time out. I have concerns about this because it must have negative consequences for server scalability and performance.
The thing you are looking for is websocket https://en.wikipedia.org/wiki/WebSocket