Ive done a lot of researching but I'm a bit overwhelmed by the possibilities i seem to have.
What i want to achieve:
I need to develop a web interface on a linux/windows server, which communicates through tcp via the opc protocol to control some leds.
the plan is that the web interface would open a tcp socket server, where the clients with the leds can connect. when the user gives data to the web interface, it then sends the opc data via the socket to all connected clients (or selected clients). it should also be possible for the web interface to receive answers from the clients.
the problem is, that until now i only had a web interface which i programmed in plain js/php/html, without any help of a framework or something like that.
with that knowledge it is very difficult to imagine how i should realize the communication via tcp. as far as i know plain javascript or php does not support tcp sockets.
1. Websockets
I tried to achieve a similar function with that implementation once, but the problem is that i have to write a separate websocketserver which adds another source for failings. it seemed not to be very stable, which is why i would prefer a "direct" tcp socket connection.
2. Frameworks
Is there a framework which can level me up from plain js/php/html which adds the required functionality? what additional function would a framework give me? I'm not quite understanding the need of a framework.
3. ASP
asp.net seems to be what i want to achieve. a "single-application" web interface which can also target server hardware like tcp or serial. But the problem would be, i think, the enourmous learning curve when developing such an app. i'm also not sure if mono can run the asp.net with full functionality at the moment.
So long story short, what would your approach be?
I think you can do that in Mono and ASP with no problem. But considering that you started your project in php, you can use tcp/ip sockets with it:
PHP TCP/IP example
Best regards
Related
So, I've created a MySQL database on AWS RDS, and written a client desktop application in a .NET application that uses Sockets to authenticate with, connect to, and manipulate the database, using the endpoint ("xxxxxx.rds.amazon.com") and username/password. This works great.
I was trying to see if I could accomplish something similar in client javascript. It seems like the analogous API it offers is WebSockets, which I am familiarizing myself with. However, it seems to me (mostly from the absence of how-to's on the web) that that endpoint ("xxxxxx.rds.amazon.com") is accessible via Sockets, but not via WebSockets -- and that there is not an alternate route to my MySQL database for WebSockets. Is this correct?
It makes sense that these are two different types of servers, but generally speaking internet resources are served out to Sockets, but not WebSockets? If that is true, they are not as analogous as I originally thought; is WebSockets mostly good for communicating between WebSockets clients and servers that I create? Or can it be used to access good stuff already existing on the internet, as Sockets can be?
(Note: this isn't asking for opinions on the best way to do this, I'm just confirming my impression of the specific way these technologies are used.)
Thank you.
I have a requirement to create a browser plugin. It should be a cross-browser plugin. The look and feel is similar to, say, Ask toolbar. My browser plugin should be able to make calls (using Cisco call control). Internally we will handle that no issue in that. But what is required is that previously we developed website for handling calls, which used java applets to dynamically change the status {Example when there is an incoming call Answer button would get enabled}. Will I be able to achieve it in Browser plugin.
Can I be able to use browser plugin over applet?
Is there any replacement for Java applet in the browser plugin?
Please help me in making a dynamic browser plugin.
Update:
I am planning to go for Kango cross-browser extension Framework. I need to know if Kango or any other extension framework support a socket communication where it can listern for sever update.
Thanks.
Can I use WebSocket (supported in HTML5) in the browser Extension? I learned that WebSocket method could not communicate directly with ordinary server and it need some changes in the server as well.
Ref: Connect to standard socket using WebSocket
Is there any other way other than WebSocket ?
Is there any open source available for javascript library which uses flash player?
If it could be opensource it could be helpful.
Cross browser plugin can be developed using some extension development tools such as Cross Rider or kango . I feel that Cross rider provides good support.
If we are going for Java applet for socket communication, definitely we are ready to face some trouble. Better avoid Java applet.
Socket communication can be achieved in the Web browser using many ways. "Web Socket" is one of them. The only constrain in using it is that it is supported only in HTML5 supporting browser or browser version. IE give support to WebSocket from IE11 only.
Another way to go is using Socket.io . It is having a good way of achieving it by using the available techniques in the client browser. For Example, if the client browser do not have a Flash player (Flash supports socket communication), it uses WebSocket or it "fallback" to available technique supported in browser.
Even node.js is a light weight technique.
The challenge here is we could not communicate with server which support socket with a "websocket" client. We need a proxy, Ref: Connect to standard socket using WebSocket
Hope this should help who need some start on Web Socket communication. If anyone want to add to this I would be very happy.
In my iphone application I am calling (by SOAP post method) a web service which is written in .net and hosted on a server, and its all working fine. But my doubt is, can we write a web service in objective c? And host it on a server? so that we should be able to access it from any of the platforms like .net, php and objectiveC.
I read a fantastic tutorial regarding this question some time ago here.
To be honest, it can be quite difficult to really use this in a productive environment. If you want to get all the features and tools Apple gives to you (what seems to be the intention of your question), you'll have to use a Mac in order to run your service afterwards.
In my opionion using PHP for example (if you need a db also backed up by MySQL) is much easier. Almost all hosters support it and you won't have to worry about setting up a bunch of macs and connecting them via solid and stable cables to the internet (and with that: guarantee availability).
Yes. A web service is just some application that can provide a service over the web. As you can create an application in Objective C, it can be a web service the same as made in any other language.
You can make it run on any server where you have an objective C compiler, however, the framework you use may restrict your choices to the server (ie, you can write objective C on windows, but you wouldn't be able to use the NS framework)
Web services are not limited to a programming language, however you do need to find if there is any framework using objective-c can run on specific server. For example, iiS allows you to use Asp.net which could be implemented using C# or VB.Net.
From the clients who will consume web services, they don't have to be a specific type of device. I think that's the point of web services. The messages travel in between is formatted. For example, a SOAP message is using xml, and that would ensure the message travel on HTTP. Therefore no matter you use iPhone or Android or Blackberry, you should have no problem to make web service calls.
So in general, I think you have to see what kind of web services you want to create, and then see if Apple(I assume) can provide you with a good framework to do it. In terms of client side, as long as your web services are using XML or JSON, it should be well supported.
Hope it helps.
First off, I intend no hostility nor neglegence, just want to know people's thoughts. I am looking into bi-directional communication between client and server; client being a web application. At this point I have a few options: MS-proprietary duplex binding, from what I hear unreliable and unnatural: comet, and web sockets (for supported browsers).
I know this question has been asked in other ways here, but I have a more specific question to the approach. Considering web sockets are client-side, the client code sits in JavaScript. Is it really the intention to build a large chunk of an application directly in JavaScript? Why didn't W3C do this in web services? Wouldn't it be easier if we were to be able to use SOAP to provide a contract and define events along with the existing messaging involved? Just feels like the short end of the stick so far.
Why not make it simple and take advantage of JS dynamic nature and leave the bulk of code where it belongs....on the server?
Instead of
mysocket.send("AFunction|withparameters|segmented");
we could say
myServerObject.AFunction("that", "makessense");
and instead of
...
mysocket.onmessage = function() { alert("yay! an ambiguous message"); }
...
we could say
...
myServerObject.MeaningfulEvent = function(realData) { alert("Since I have realistic data...."); alert("Hello " + realData.FullName); }
...
HTML 5 took forever to take hold....did we waste a large amount of effort in the wrong direction? Thoughts?
Sounds to me like you've not yet fully grasped the concepts around Websockets. For example you say:
Considering web sockets are client-side
This is not the case, sockets have 2 sides, you could think of these as a Server and a Client, however once the connection is established the distinction blurs - you could then also think of the client and the server as "peers" - each can write or read in to the pipe that connects them (the socket connection) at any time. I suspect you'd benefit from learning a little more about HTTP works on top of TCP - WebSockets is similar / analogous to HTTP in this way.
Regarding SOAP / WSDL, from the point of view of a conversation surrounding TCP / WebSocket / HTTP you can think of all SOAP / WSDL conversations as being identical to HTTP (i.e. normal web page traffic).
Finally, remember the stacked nature of network programming, for instance SOAP/WSDL looks like this:
SOAP/WSDL
--------- (sits atop)
HTTP
--------- (sits atop)
TCP
And WebSockets look like this
WebSocket
--------- (sits atop)
TCP
HTH.
JavaScript allows clients to communicate via HTTP with XMLHttpRequest. WebSockets extends this functionality to allow JavaScript to make arbitrary network I/O (not just HTTP), which is a logical extension and allows all sorts of applications that need to use TCP traffic (but might not be using the HTTP protocol) to be ported to JavaScript. I think it is rather logical that, as applications continue to move to the cloud, that HTML and JavaScript support everything that is available on the desktop.
While a server can do non-HTTP network I/O on behalf of a JavaScript client and make that communication available over HTTP, this is not always the most appropriate or efficient thing to do. For example, it would not make sense to add an additional round-trip cost when attempting to make an online SSH terminal. WebSockets makes it possible for JavaScript to talk directly to the SSH server.
As for the syntax, part of it is based on XMLHttpRequest. As has been pointed out in the other posting, WebSockets is a fairly low-level API that can be wrapped in a more understandable one. It is more important that WebSockets support all the necessary applications than that it have the most elegant syntax (sometimes focusing on the syntax can lead to more restrictive functionality). Library authors can always make this very general API more manageable to other application developers.
As you noted WebSockets has low overhead. The overhead is similar to normal TCP sockets: just two bytes more per frame compared to hundreds for AJAX/Comet.
Why low-level instead of some sort of built-in RPC functionality? Some thoughts:
It's not that hard to take an existing RPC protocol and layer it on a low-level socket protocol. You can't go the opposite direction and build a low-level connection if the RPC overhead is assumed.
WebSockets support is fairly trivial to add to multiple languages on the server side. The payload is just a UTF-8 string and pretty much every language has built-in efficient support for that. An RPC mechanism not so much. How do you handle data type conversions between Javascript and the target language? Do you need to add type hinting on the Javascript side? What about variable length arguments and/or argument lists? Do you build these mechanisms if the language doesn't have a good answer? Etc.
Which RPC mechanism would it be modeled after? Would you choose an existing one (SOAP, XML-RPC, JSON-RPC, Java RMI, AMF, RPyC, CORBA) or an entirely new one?
Once client support is fairly universal, then many services that have normal TCP socket will add WebSockets support (because it's fairly trivial to add). The same is not true if WebSockets was RPC based. Some existing services might add an RPC layer, but for the most part WebSockets services would be created from scratch.
For my noVNC project (VNC client using just Javascript, Canvas, WebSockets) the low-overhead nature of WebSockets is critical for achieving reasonable performance. Until VNC servers include WebSockets support, noVNC includes wsproxy which is a generic WebSockets to TCP socket proxy.
If you are thinking about implementing an interactive web application and you haven't decided on server-side language, then I suggest looking at Socket.IO which is a library for node (server-side Javascript using Google's V8 engine).
In addition to all the advantages of node (same language on both sides, very efficient, power libraries, etc), Socket.IO gives you several things:
Provides both client and server framework library for handling connections.
Detects the best transport supported by both client and server. Transports include (from best to worst): native WebSockets, WebSockets using flash emulation, various AJAX models.
Consistent interface no matter what transport is used.
Automatic encode/decode of Javascript datatypes.
It wouldn't be that hard to create a RPC mechanism on top of Socket.IO since both side are the same language with the same native types.
WebSocket makes Comet and all other HTTP push type techniques legible by allowing requests to originate from the server. It is kind of a sandboxed socket and gives us limited functionality.
However, the API is general enough for framework and library authors to improve on the interface in whichever way they desire. For example, you could write some RPC or RMI styled service on top of WebSockets that allows sending objects over the wire. Now internally they are being serialized in some unknown format, but the service user doesn't need to know and doesn't care.
So thinking from a spec authors POV, going from
mysocket.send("AFunction|withparameters|segmented");
to
myServerObject.AFunction("that", "makessense");
is comparatively easy and requires writing a small wrapper around WebSockets so that serialization and deserialization happens opaquely to the application. But going in the reverse direction means the spec authors need to make a much more complex API which makes for a weaker foundation for writing code on top of it.
I ran into the same problem where I needed to do something like call('AFunction', 'foo', 'bar') rather than serialize/de-serialize every interaction. My preference was also to leave the bulk of code on the server and just use the Javascript to handle the view. WebSockets were a better fit because of its natural support for bi-directional communication. To simplify my app development, I build a layer on top of WebSockets to make remote method calls (like RPC).
I have published the RMI/RPC library at http://sourceforge.net/projects/rmiwebsocket/. Once the communication is setup between the web-page and the servlet, you can execute calls in either direction. The server uses reflection to call the appropriate method in the server-side object and client uses Javascript's 'call' method to call the appropriate function in the client-side object. The library uses Jackson to take care of the serialization/deserialization of various Java types to/from JSON.
WebSocket JSR was negotiated by a number of parties (Oracle, Apache, Eclipse, etc) all with very different agendas. It's just as well they stopped at message transport level and left higher level constructs out. If what you need is a Java to JavaScript RMI, check out the FERMI Framework.
I want to implement a chat service on my site, and wonder how to create a simple browser-based IRC client from scratch?
I have a linux box and can install whatever I want on it. Google finds tutors on how to setup an IRC server but no instructions on how to create an IRC client.
(As client languages, I can use JavaScript or Flash.)
As you are already familiar with JavaScript, I would recommend a combination of Node.js, Now.js and node-irc.
Node.js is an application that enables you to run JavaScript server-side and to develop web-applications very fast.
Now.js is a library for Node.js that enables you to RPC between client and server. You can just call a function on the server from your client application and vice-versa; their developers guide is in fact a web chat ;)
node-irc is also a library for node.js that enables you to easily create an IRC client.
Combine these three and you get a very nice, very easy self-coded web chat. For the browser interface, there are many possibilities, including application frameworks like ExtJS, JQueryUI, KendoUI or something easier.
http://www.lightirc.com/
http://wdmedia.org/WFIC/index-en.html#sectiondescription