I will be having a software which will give me information about the moving vehicles on the server side and I need to pass this information to the client computer on demand.
There will be a website which will act like a server and another website will act like a client. The client
website will ask for a data from the server website.
From here: https://stackoverflow.com/a/2849683/462608
As the protocol may not be HTTP, you may provide WebServices over mail or other protocols, and you do not need a web server for that.
I request an explanation on the above quote. In my case will I be needing a webserver?
There is a bunch of webservice protocols, some of them may use and some may not use http as transport layer. When http is used - you need a webserver on server-side of your service and a webbrowser as a client. If the transport is other than http, you need server of other type, and other client, for example, mail server and mail client in case of running service over smtp.
Related
I have a web application hosted on an external server. I would create a communication beetwen my home server and the web application.
I thought something like that:
my home server send its ip to the web application
the web application send data to the home server
my home server send back some data
I want to implemente a P2P communication between the WebApp and the home server
it would be bettere if the communication is encrypted
i dont want to use dynamic dns
Is there something to implement that?
There are several types of IP. It can be "grey" and "white".
"Grey" means that your computer can't be accesses through it.
"White" IP's can be accessed directly. Also there are dynamic IP's
that changes through the time. It all depends from the provider.
It's possible that you have "white dynamic" IP but it's pretty rare
for providers to do.
It's easier to connect to server because it
always have "white" permament IP.
TCP/IP already does most of the work. You just create tcp connection and it stays. You just think about sending data.
My suggestion for you is to create something like this:
Home server connects to WebApp
Home server requests some data and WebApp sends back data
Home server sends request containing data and server respondes that all is ok
So you have client-server model. And client always does only requests and server does only responses. And they do not switch. It's easier to maintain.
There is common technology of doing that and it includes encryption too.
You should use HTTPS protocol. Https will do all the encryption(and safely exchange keys too) you just worry about certificates(there are ways not to buy certificate but sign them by yourself. It's whole another topic)
So you will send https requests from your home server PC(client) and get responses from server(webApp).
As you write on Python you would find this answer helpful for you:
HTTPS request in Python
I'm developing an iOS app that requires realtime dual-way server/client messaging.
I'm trying to use WebSocket++ to develop a WebSocket server app on an AWS EC2. Have to use C++ because that's the only language I know on the server side.
The problem is I'm a fresh guy on server side development. I have 2 very basic questions:
1, Do I need have to setup an HTTP server like apache/nginx in order to get websocket running?
That is, can websocket app live independently alone?
2, I have now setup an nginx server in case it is a must have, is there any resource that I can refer to to make nginx & websocket work together well?
No, you don't need a Web server, a (reverse) Web proxy or anything to have your C++ WebSocket server talk to WebSocket clients.
Nginx (as HAproxy) supports reverse proxying WebSocket. This can make sense in certain situations, like you want to terminate TLS at the proxy and forward plain WebSocket to your backend server, or you want to load-balance incoming WebSocket connections to multiple backend nodes. However, as said, this isn't required.
No you don't, websocket and socket for an HTTP server are two diffent things.
HTTP server is for the HTTP protocol while there is not protocol defined for websocket, you have to define it yourself typically by the mean of sending/receiving Json message (a stream of character which each side (the server and the client) knows how to read/write).
The goal of websocket is to offer to javascript through HTML5 an easy, light and quick way to communicate through a socket, without websocket you have to do that with web services and in that case you need a http server.
With websocket you can create an html file leveraging html tag and javascript, javascript use client side of websocket to communicate with a C++/websocket server program, and you do not need even a web server, in this scenario you have a "desktop web app" ! (here web term is only because you use html tags)
Same question, same answer, no again ;-)
Good luck, and welcome in the wonderful world of asio !
As I mentioned in the title: I would like to know the difference between the web-service and the web-socket? when we used each one?
Thanks!
A web service is an HTTP server that responds to client SOAP/REST/JSON requests.
A web socket is a client-side API that allows a web browser to create a bidirectional communication link with a server without having to change/reload the current page. This is typically used for AJAX requests to dynamically update live content on the current page, or create chat sessions between clients, or implement custom protocols that run in the web browser.
Web services are based on HTTP protocol and use HTTP methods to relay data in a request and response paradigm. Thus the client will always be the one responsible for communicating with the server, requesting data and submitting data to the server i.e getting list of customers or products, adding products or customers to server.
In contrast, Web sockets allow bidirectional communication, meaning server can initiate communication as much as client can do the same. Typically you supply a host IP Address and port to the socket. Web sockets can be used to implement a chat application.
The key difference between Web sockets and Web services is that with web sockets you get bi-directional connection in which the server and client can continuously send messages back and forth while Web services are uni-directional connection concerned with supplying clients with resources
On the doc Specifying WebSocket authentication details, it did not mention how are passwords being sent from client's authenticate() JS func to server's onWSAuthenticate. Are they being sent through a secure channel? or in plain text?
Side question: what tool / browser / browser's plugin can one use to sniff through websocket's traffic?
Thank you.
username/password sent through authenticate() function is in clear-text. You can actually see that in cfwebsocket.js (its minified so search for authenticate). On server if the call is for authentication, it would invoke onWSAuthenticate() in application.cfc passing whatever username or password given to the function. So the logic of encryption/decryption/validation lies with the developer.
Any TCP monitor can be used for sniffing websocket's traffic like wireshark , TCPMon etc
Mostly just answering to further my own understanding of how this works. From the websocket.org site:
The tunnel is established by issuing an HTTP CONNECT statement to the proxy server, which requests for the proxy server to open a TCP/IP connection to a specific host and port. Once the tunnel is set up, communication can flow unimpeded through the proxy. Since HTTP/S works in a similar fashion, secure WebSockets over SSL can leverage the same HTTP CONNECT technique.
So, if this is what you're asking, it appears that just like with http/https, it's up to the developer to implement SSL encryption, which makes sense.
Sagar Ganatra also has a blog entry on the basics of Websocket Authentication with CF.
I need a system in which I can send SOAP request to 1 server from a few and then if server has this service it calls and returns value to client.
If not it passes the request to next server on his "list of neighbors". Request is passed until some server has needed service (or not, so we return error result).
My question is. What will be the best way to communicate between those servers. SOAP? Message Driven?
It will be great If it could work without central server. If I will use MD, should not all servers use common JMS on some central server?
Is it possible to send MD to specific server on given address?
Take a look at Apache ActiveMQ or Apache Camel or Spring Remoting