I would like to have ASP.NET Core based website with communication to ESP32 (microcontroller with program based on Arduino code) which would have keep-alive connection. Something like serial-port without cable over network. I figured out that websocket might work and be the best solution (or not?). ESP32 doesn't support SignalR so I have to go raw websocket. I found only middle-ware solutions without support to be called from controller.
Idea is: Keep-alive connection between ESP32 and ASP.NET Core website. User can go to website and trigger action (from browser/api) which will send data to ESP32. Website is public-part. Browser and ESP32 are closed parts (I mean.. no public ip address). Also I would like to send data immediately after action is triggered. It would be nice if ESP32 would receive data within 3 seconds.
Is websocket correct idea? Can you show me or direct me how to send data from action to websocket client? I couldnt find enough informations how to make it.
Instead of Websocket I finally used TCP via TcpListener running as IHostedService. I made Singleton class with Queue to queue messages from API calls. In IHostedService while cycle I checked if there is any new queue message to send.
ESP32 connected via Wifi using WiFiClient library.
Simple & fast
Related
I need a ClientWebSocket wrapper in order to connect and collect data from wss://stream.binance.com:9443. The received data should be broadcasted to the UI (realtime UI) through a web socket server.
The broadcast part can be achieved using SignalR .NET Server. It is documented on MSDN.
The client web socket part is what I can't imagine. I found a SignalR .NET Client that I can use to connect to wss://stream.binance.com:9443, however I don't think it is possible, because SignalR probably has its own transport protocol. Is it correct?
If the Signal .NET Client doesn't work in my case, could you please direct me to alternative solutions? I was looking at the following
https://github.com/Marfusios/websocket-client
https://github.com/skunklab/piraeus/tree/96fcbc854d0c8d2c2cd62e457f06ef638859b6eb/src/SkunkLab.Channels/WebSocket
https://gist.github.com/xamlmonkey/4737291
It's worth stating that the ClientWebSocket subscriptions to Binance will be created for multiple API keys (unknown amount of users - based on DB user records).
At the moment I'm writing a small program in C# for windows 7 which can send notifications over GCM (Google Cloud Messeging) to my Android smartphone. For this I send some data via POST to my WebServer which then pushes the data over GCM to my smartphone. That works great in this way but I also want to send some data to my program from my Smartphone.
My problem now is that I do not know how I can notificy my C# program from my WebServer. I thought about something like this:
Smartphone -> send Data to WebServer -> notify C# program
I do not want to use polling and the GCM client is only for android smartphones. So what do you think is the best way to notify my program that some data is avaible for it? I read something about HTTP streaming but I do not know how it works and have no idea if I can implement it with C#. Or do you have other ideas how I can solve this problem?
SignalR is a good shout but you should also understand the base concepts of socket programming. C# makes it really easy to open a socket and listen for messages. The Microsoft website shows you how to handle a requests synchronously here.
Http is just a message protocol. Once you understand the protocol reading the messages is not too hard. Remember if you are receiving messages from the server it will need to know your IP address etc.
My server has two applications running on it:
TCP socket server that continuously accepts and sends messages to and
from clients (C# .NET Winforms)
ASP.NET application
What I need is:
When a message is received from a client via the TCP connection (app 1) I want the ASP .NET application (app 2) to reflect this data dynamically. I realise that I can set database entries via the TCP socket, which will then be picked up by the ASP.NET application.
A way of sending messages to clients from the ASP .NET application to clients that are available inside of the TCP socket server
e.g. A simple chat program where a client sends “Hi” and server responds “Welcome”. The ASP .NET should show a log of this conversation as it happens. Immediately. And if I click a button on the ASP application, it should send a message on behalf of the socket server to the client “You have been accepted onto the server”
For the most part, the messages are going to be fairly short like the ones shown here.
What is the best way to do A and B?
SignlaR is a good solution if you're getting the messages from another SignalR client (web page).
But what if these messages are being sent from a 3rd system over TCP/IP?
Then you need to open a TCP port in the ASP.NET Web Application and after receiving a message you have to push it to the web clients.
But the question is, what is the best way to have such a TCP Listener hosted in a Web Application (ASP.NET)?
if your "messages" are mostly textual, you may want to take a look at SignalR.
SignalR is a new library for asp.net to enable real-time web functionality.
It uses websockets (or long polling if websockets is unavailable at server/client).
It has support for different client types.
I am developing a game in Flex.
There are both AIR and Web versions of this game.
AIR app would connect to a server using a UDP socket on a port.
The purpose of the Web version is to allow users to play when they are at work, or on a computer behind some firewall/proxy that blocks some ports. So the web would connect to a server using http connection on port 80.
The server code answering the http connections would be a java servlet that uses BlazeDS.
But if any of you find it more easier to explain for a C# server code(webservices or whatever), it would be ok .
The server code answering the UDP requests would be a simple class listening for socket connections.
My problem is I don't know how to put UDP and http code together. If there are 5 AIR clients, and 5 Web clients, they all need to meet in the server in some common collection variable, so that I can update all clients with latest info.
Who is going to instantiate the class that listens for sockets? And when?
So to summarize:
1. Do I need a dedicated server to achieve what I want?
2. Who will instantiate the udp handling class and when?
3. Is it even possible to keep the udp handling class and the servlet for http connections together? If there would not be http, I wouldn't even need tomcat. But http and udp code need to stay together, so that I can update the players collection. Is it possible to instantiate the UDP handling class and tell it to listen for socket when the servlet is deployed on the server...or something like that?
Any advices are more then welcome.
Thanks in advance,
Miha
http and udp code need to stay together
No they don't. They are transport mechanisms for your game data, so they should be transparent. Your UDP and HTTP servers should connect to your game backend, in what way is up to you. It can be in-memory, by using HTTP and UDP (socket) modules directly from your backend code, or it could be using some sort of service (so you can let other channels talk to the same backend).
This game backend does not connect directly to the user but only talks to the UDP and HTTP modules.
Then from this backend you process messages you receive from both HTTP and UDP, and sends the response over the same channel.
Example:
AIR-client 1 sends a valid login message to UDP server.
UDP server forwards the login message to the game backend.
Game backend returns succesful result message to UDP server
UDP server forwards the result message to AIR-client 1.
Example 2:
Now HTTP-client 1, which happens to be already logged in, requests all users currently logged in. It does so over HTTP, to the HTTP server.
HTTP server forwards this request to the game backend.
Game backend returns information to HTTP server
HTTP server returns response to client.
I’m trying to write a custom TCP based long polling server that will serve as a go-between for other TCP connections that require more persistence than a mobile phone can provide.
The way I’m trying to do it is writing an asynchronous TCP server in C# and a matching TCP Client also written in C#.
The way that long polling works (as far as I understand it) is that you open a TCP connection to a server, and the server Halts before sending data back across the socket. You find a Heartbeat interval that works on a mobile phone network (I’ve heard that around 8 minutes works?) and you send an empty packet if there is no updated data.
This is where my trouble comes in. I can’t figure out how to “link” my client’s request for data with an event handler running on the server…
The flow should be something like this (“client” is on a phone):
User starts my application
Client sends a request to be notified if data has changed
Server “links” (registers) client’s socket object into an “Event handler” that is called by the server’s other TCP connections that I talked about!
Event
o If it is triggered (new data has arrived), Send the data to the client
o If it isn’t triggered (no new data), Send an “EmptyChanges” packet to client
Client receives data on the phone and processes it (calls an event handler based on what type of packet it received and passes the “data” it got from the server to it)
Client sends a request to be notified if data has changed
So, my problem is that I can’t think of a design that will accomplish what I want it to do. The problem is that I don’t know HOW to do #3. How do I “Link” one event handler from another? And these are almost guaranteed to be running on different threads!
So, my application would look something like this (all psuedocode):
Class AppClass
{
Main()
List<Client> clients;
List<DataServers> dataServers;
DataReceivedFromServer(Data stuff)
{
}
MessageReceivedFromPhone(PhoneMessage pm, object sender)
{
//Loop here until HeartBeat interval reached
Int totalTime = 0;
While(totalTime < HEARTBEAT_INTERVAL)
{
If( ) // If we have received data from the server, and the client WANTED that data, send it now
{
}
}
}
}
Kind of? I want it to be event driven, but I'm having the damndest time figuring out how to drive the application with a PUSH driven style vs. what I'm "used" to of Polling.
Please, be kind as I might be doing something overly complicated and stupid because this is my first real attempt at using Socket programming (never needed it) and it's especially hard due to the nature of Cell phones being on transient networks and my server needing to maintain the location of these phones with an OPEN TCP connection.
Server platform: Windows
Server language: C#
Test Client platform: Windows
Test Client language: C#
Target Client platform: Windows Mobile 6.5, iPhone, Android (clients will be written separately)
Target client language: C#, Obj-C or MonoTouch, Java
Just anyone wondering this, I trashed the idea of writing a custom TCP server to manage my connections. There was so much overhead in doing that, I'd basically be replicating writing my own HTTP server, so instead of doing that, I went with the Web Tornado framework in Python as my server and am writing the back end services to communicate through HTTP requests in Web Tornado.
Instead of using Long polling at all, I'm going to use SMS for push notifications. I believe all of the major phone platforms implement something similar to an SMS Interceptor that you write... if an SMS of a certain format comes through, it will run your custom code. This allows me to remove the requirements of using consistent open connections (other than for live chat, which will use a comet style Long poll, but the connection can only remain open if active for about 5 minutes.)
Basically, the Web Tornado framework is serving as an Enterprise bus in my architecture.