I need to develop an application which would run in a corporate network. The client should both receive commands (shutdown, restart, ...) and send info (something happened, ...) from/to the server. So, using a web interface, the network administrator would be able to see what clients are connected, send commands to them, and see real-time info coming from them. The client should be written in Delphi (normal VCL forms with Edits, etc.) and the server "preferably" in ASP.Net.
I researched a bit and I think WebSockets might be good to achieve this. I plan to use some WebSocket libraries for Delphi like this. I'm not sure what technology I should use for the server.
Please tell me if WebSockets is good for my requirements. Other solutions are welcome (maybe writing the server in Delphi?).
Web interfaces typically are HTML based views, and require a web HTTP server and a web browser (Chrome, Firefox, etc.). Delphi Web Socket client libraries however can only be used to talk with a Web Socket server from within a native Delphi application, for example a VCL GUI.
If you plan to write a VCL application (not web browser based), you have other transport protocol options besides Web Sockets, which are widely used in small and large systems:
MQTT (formerly Message Queue Telemetry Transport)
STOMP (Streaming Text Oriented Messaging Protocol)
AMQP (Advanced Message Queuing Protocol)
MSMQ (Microsoft Message Queuing)
As with WebSockets, these protocols offer asynchronous / bi-directional messaging. On the server side you can choose from many production quality implementations of these protocols (known as 'message brokers'), mostly free / open source. Similar to HTTP, message payload can be anything - text or binary data - and messages can use headers to provide application-defined metadata.
Your server-side application code can be written in Delphi, and is only another client of the message broker, communicating with the client applications over the message broker protocol. As soon as client and server are connected to the message broker, messages can flow in both directions.
Many advanced features are included in message brokers: if a client disconnects while the server is still sending messages, the message broker can store these messages and deliver them as soon as the client reconnects.
For most of these protocols I have seen client libraries or wrappers for Delphi / Object Pascal, free and open source or commercial.
Related
short question : How can I host an MQTT server on my remote Ubuntu 16 server while at the same time hosting an HTTP server that will be using the MQTT data ?
true question : I want to build an IoT system that will be MONITORED and CONTROLLED by ESP32, which will SEND FEEDBACK and ACCEPT COMMANDS respectively from a remote server (maybe LAMP ?). I also want the user to log-in in a website hosted on this remote server, where s/he can monitor any sensor values or send commands (e.g. turning a led on or off).
So what's the way to go here?
I was adviced to go with MQTT but then the above problem arised.
what I've found : I 've found that using Mosquitto MQTT, I may be able to serve a website using websockets. But I prefer a more scalable HTTPS approach. That is, I intend to have a database linked with my site and running my PHP scripts.
I'm not that experienced, so please don't take anything for granted :)
MQTT uses TCP connection and follows publish/subscribe API model where as the web(http) follows Restful API model(Create,read,update,delete). If you want to stick with MQTT then you should use SAAS service like enterprise MQTT from HIVE which provide this integrability but will charge some fees and in return, they will provide you with an account and a dashboard for all your devices. Otherwise, you can try to make your own middleware which can integrate MQTT with web services .
Another thing I would recommend is CoAP which is also an M2M protocol but follows Restful API model and UDP connection. It has direct forward proxy to convert coap packets to https packets and vice versa.
In MQTT you have a central server(Broker) to which the nodes send their data and fetch their required data through topic filters.
In CoAP each device having some data to share becomes a server and the other device interested in it's data becomes a client and sends a GET request to the respective server to get its data. Similarly a PUT request along with a payload from a client would update the value at the server.
You really should not be looking to combine the MQTT broker with a HTTP server, especially if you intent the HTTP Server to actually be an application server (Running back end logic e.g. PHP). These are 2 totally separate systems. There is nothing to stop your application logic connecting to the broker as a client.
If you intend to use MQTT over WebSockets you can use something link nginx to proxy the WebSockets connection to the broker so it can sit behind the same logical HTTP/HTTPS address.
Help needed please
What's is the best WebSocket client library for a .net 4.5 on windows web application hosted on windows 2008 servers to connect to a remote server web socket.
The scenario is: our web application will use a web socket to connect to a server WebSocket on a third party infrastructure. Our client WebSocket will connect and send some commands and read the responses where we can identify the information needed. So there is no interaction from the user or browser its just in the code. e.g. user clicks a button and we go and get some data, and give a message dependant on the response.
so for example our client will connect to the third party socket and pass the users car registration number and send a tell me the car details and the server socket will return the data like: make, model, year etc... so we can then display that to the user.
Has anyone used this library with some good success? http://www.nuget.org/packages/WebSocket4Net
I'm hoping someone here can provide the best approach for doing this with some tried and tested solutions. I have been thinking about a web API that handles all the socket stuff in our client so i can call it and let it handle the close connection etc.
I have a use case where we will have an ASP.NET MVC Server Application but it needs to talk over a persistent connection to a Windows service. It doesn't look like SignalR does this as it really wants talk Server to JavaScript browsers but I did notice .NET desktop libraries. Can it talk from a server to a Windows server? If not, is there a recommended way, TCP/IP or HTTP to have a persistent connection between the two? NetTcpBinding in WCF?
Yes, there is a SignalR client library for .NET that you can use in any old .NET app to talk to a SignalR server just like you can from JavaScript.
While there is a WebSockets binding for WCF, there is no binding that actually talks native SignalR which adds its own message framing on top of raw web sockets. So, while possible, it doesn't exist today and I wouldn't hold my breath for it ever being created.
Why not simply have a queue using RabbitMQ. And anytime the web need to talk to window service, it push a message into the queue while the window service listen to the queue
I am working on asp.net web based peer to peer chat application. I am using UDP sockets for communication. As my application is P2P I should avoid interactions with server and let peers to send and receive their messages.
Now my doubt is where am I suppose to write socket related coding? If i write socket related coding in controller classes, the coding comes under server side right? Every time user sends a message from browser it will call my controller class where my sockets were defined, and will send messages to the remote peer. Does this kind of socket programming (sockets defined in controller classes) will result in peer to peer application?
In Peer to peer communications, you do not pass any data via your server, but let the clients communicate to each other directly.
In web applications, true P2P is near impossible to achieve.
You could try to achieve something not-entirely-unlike peer-to-peer communication with javascript and HTML5 websockets on the clients.
In this scenario, you would use your asp.net server as a broker to set up the connections between your clients.
(since your server knows where to reach your clients).
Your javascript clients should from that moment on handle the rest of the communication business.
I want to open a connection back to the server using Flex so I can stream chat messages to the Flex front-end. How do I do this and does Flex enforce any same-origin restrictions on ports or subdomains?
You'll have to use a messaging server software and then use the Producer and Consumer classes in the Flex framework to send and receive messages.
What you need depends on what server you are running on. If you are on a Java stack, you can use BlazeDS and ActiveMQ.
If you are streaming/consuming from and to different domains, you'll need to setup a crossdomain file that allows the inter-domain communication.