I have an existing AWS solution which includes the following. It uses a legacy application (written in C#) running on an EC2 instance. This legacy application implements a TCP server and listens on a specific TCP port. It contains custom code to decode the data and dump it into a database. The choice of the database is less important for now.
I'm after a more contemporary solution based on AWS which can potentially deprecate the existing legacy application. Most options with Amazon IoT involve HTTP and MQTT. I can't change the protocol. It must still be a TCP.
The closest thing I can find is Amazon IoT Greengrass (https://aws.amazon.com/blogs/iot/converting-industrial-protocols-with-aws-iot-greengrass/) which appears to involve running a TCP client in an AWS lambda function, and then forwarding it to MQTT / AWS IoT Core.
I'm curious what other approaches may be possible.
Related
I have an existing solution for acquired IoT devices that have proprietary legacy firmware, that uses raw TCP.
The solution involves an application written in Node.JS running on an AWS EC2 instance. It creates a TCP server that opens a socket to listen to the device (each of them). Every time the IoT device pings the server, the server must ping back the device with a default message (created using the original message) as validation the connection is still online.
After pinging back, it then unscrambles the TCP data parsing it into Json and adding to a MongoDB database. Which then is used for displaying data to the customers.
Also, on the same EC2 instance, another application is deployed on-demand via front-end APIs requests to send commands to the IoT devices and logs it into the same DB, sometimes changing constants that are defined to each device separately.
As we are developing new devices in MQTT protocol, we are creating new serverless architecture using AWS IoT Core. I'm looking for an innovative serverless solution to integrate the legacy devices in this more robust and less demanding architecture (more cost effective).
As I can't change the protocol, it must still be a TCP, i'm looking for something to convert the TCP into MQTT and then forward it to the general IoT Core. That way, i can use the same architecture for both new and old devices. Giving me time to slowly decommission the older devices, not having to maintain both infrastructures.
The closest thing I've found is Amazon IoT Greengrass (https://aws.amazon.com/blogs/iot/converting-industrial-protocols-with-aws-iot-greengrass/), which appears to run a TCP client in an AWS lambda function, and then forwarding it as MQTT into AWS IoT Core.
We are testing this now, but i would like to know if anyone had similar issues with legacy protocols using Greengrass or other solutions.
I have a situation where I want to use Google IoT Core to support bi-directional communication between my devices and existing GCP stack. The trouble is, some of my devices cannot connect to GCP's MQTT bridge because they are blocked from reaching it directly. The communication must instead go through my own hosted server. In fact, some devices will not be allowed to trust traffic either inbound or outbound to anything but my own hosted server, and this is completely out of my control.
Basically all suggested solutions that I have found propose the use of MQTT over WebSockets. WebSockets consume too many system resources for the server I have available, and so MQTT proxy over WebSockets is extremely undesirable and likely is not even feasible for my use case. It also defeats the purpose of using a lightweight, low-bandwidth protocol like MQTT in the first place.
To make matters more complicated, Google IoT Core documentation explicitly says that it does not support bridging MQTT brokers with their MQTT bridge. So hosting my own MQTT server seems to be out of the question.
Is it even possible to create a proxy -- either forward or reverse -- for this use case that allows for native, encrypted, full-duplex MQTT traffic? If so, what would be the recommended way to achieve this?
If you have hybrid set-up, meaning you have on-premise servers and a cloud server and you want to bridge them using Google IoT by using MQTT.
You can try in this github link, upon checking this MQTT broker has been tested to Google IoT. Since Google IoT is not supporting 3rd paryt MQTT broker.
Is it possible to use AWS Application Loadbalancer for RSocket?
An AWS Application Loadbalancer can also be used for WebSocket connections and my project uses RSocket with WebSocket as its transport. This made me wonder if it is possible to use this loadbalancer for RSocket aswell.
On one hand I would think it is possible to use this loadbalancer, as it only receives a connection and passes this to the target RSocket server.
On the other hand, if all RSocket frames go through the loadbalancer, it might not know how to handles these frames, which would make it not possible to use.
I couldn't find much about RSocket and loadbalancing online besides this post .But this is client side loadbalancing and I was looking for server side loadbalancing.
And this post .But this uses LoadBalanceSocketClient while I want to find out if an AWS Application Loadbalancer can be used.
Here follows a simple diagram of what I would like to have (if possible):
The RSocket client connects to the loadbalancer which passes the connection to a RSocket server (for example server A). Then the client and RSocket server A can communicate.
AWS will see this as a typical websocket service. So as long as it lets HTTP/1.1 connections through and lets them upgrade to WebSocket there shouldn't be a problem. This is very standard so it shouldn't be an issue. Ideally it won't see individual frames of the traffic, and you app will handle all frames on a single WebSocket connection. But it looks like the API Gateway support does deal with individual messages https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-set-up-websocket-deployment.html. You should ignore the RSocket client load balancing, and focus on AWS WebSocket routing.
As an example, with GCP (instead of AWS) the complexity is that this bumps you up from AppEngine Standard to Flexible. The demo site https://demo.rsocket.io/ is deployed to GCP and exposes websockets.
The additional kink, is that you possibly want stateful routing if you want client resumption.
i am traying to figure it out how is the best way to deploy a TCP/IP and UDP service on Amazon AWS.
I made a previous research to my question and i can not find anything. I found others protocols like HTTP, MQTT but no TCP or UDP
I need to refactor a GPS Tracking service running right now in AMAZON EC2. The GPS devices sent the position data using udp and tcp protocol. Every time a message is received the server have to respond with an ACKNOWLEDGE message, giving the reception confirmation to the gps device.
The problem i am facing right now and is the motivation to refactor is:
When the traffic increase, the server is not able to catch up all the messages.
I try to solve this issue with load balancer and autoscaling but UDP is not supported.
I was wondering if there is something like Api Gateway, which gave me a tcp or udp endpoint, leave the message on a SQS queue and process with a lambda function.
Thanks in advance!
Your question really doesn't make a lot of sense - you are asking how to run a service without running a server.
If you have reached the limits of a single instance, and you need to grow, look at using the AWS Network Load Balancer with an autoscaled group of EC2 instances. However, this will not support UDP - if you really need that, then you may have to look at 3rd party support in the AWS Marketplace.
Edit: Serverless architectures are designed for http based application, where you send a request and get a response. Since your app is TCP based, and uses persistent connections, most existing serverless implementations simply won't support it. You will need to rewrite your app to support http, or use traditional server based infrastructures that can support persistent connections.
Edit #2: As of Dec. 2018, API gateway supports WebSockets. This probably doesn't help with the original question, but opens up other alternatives if you need to run lambda code behind a long running connection.
If you want to go more Serverless, I think the ECS Container Service has instances that accept TCP and UDP. Also take a look at running Docker Containers with with Kubernetes. I am not sure if they support those protocols, but I believe they do.
If not, some EC2 instances with load balancing can be your best bet.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 3 years ago.
Improve this question
Are there any serverless technologies that allow a serverless websocket server to be built?
I know the nature of long running connections is that they are stateful, but if the only state is the connection itself at the transport layer then it seems like there could be a serverless product that abstracts this away so you only deal with the application layer. Is there a cloud provider (AWS, Azure, etc) that allows this? I can't see a way for AWS Lambda or Azure Functions to achieve this.
Anyone got any ideas? Just checking.
Thanks
With the release of WebSocket support for AWS API Gateway, you can create a server-less WebSocket API.
A WebSocket API is composed of one or more routes. To determine which route a particular inbound request should use, you provide a route selection expression. The expression is evaluated against an inbound request to produce a value that corresponds to one of your route’s routeKey values. API gateway routes the request to corresponding lambda function.
From AWS blog example,
The application is composed of the WebSocket API in API Gateway that handles the connectivity between the client and servers (1). Two AWS Lambda functions react when clients connect (2) or disconnect (5) from the API. The sendMessage function (3) is invoked when the clients send messages to the server. The server sends the message to all connected clients (4) using the new API Gateway Management API. To track each of the connected clients, use a DynamoDB table to persist the connection identifiers (You can also use it to store other state information about the connection).
You can extend this to send messages to clients on any changes to data using DynamoDB Streams
Currently AWS Lambda and Azure Functions doesn't support this. If you plan to setup an scalable environment in AWS with websockets, you can use Application Load Balancer and in front of ECS cluster or EC2 instances with Websocket supported server like NodeJS.
Another solution is to go with fully managed services, like Google Firebase Service or Pubnub in your architecture to handle the real-time part.
if the only state is the connection itself at the transport layer
That's not really the case. Web socket connections exchange keep-alives as layer 7 payload. Others might argue that it's more accurately described as a sublayer somewhere between layers 6 and 7... but in any event, it is well-above the transport layer.
And many applications use web sockets in other ways that are also not stateless. Once connected, then authenticated, there's no need to continually re-authenticate, because the client on the socket now will be the same client 15 minutes from now, and this is overhead that would not be avoidable in a serverless environment -- every action on a websocket would need to be re-authenticated. For another example, with a constant data stream, the server might keep track of what has been sent or what specific subset of the stream the client is interested in.
If you aren't maintaining (or don't need) a persistent connection to a server, the question could be asked "why are you using a web socket?"
Perhaps also relevant: HAProxy, a commonly used load balancer with web socket support, maintains a persistent connection to a single back-end server for each current web socket connection. If that backend server goes offline, there's no provision in the balancer to choose another back-end for the existing connection. The client will need to reconnect.
AWS IoT provides MQTT endpoints and it supports MQTT + WebSocket on port 443. This might be the closest thing you can get as a hosted service on AWS.
Check this link: AWS IoT Protocols
You can define rules that trigger Lambdas on AWS IoT or pass them to Kinesis and process streams through Lambdas.
Fanout can do this. It works as a proxy that can translate WebSocket client activity into a series of HTTP requests. This allows FaaS backends like Lambda to manage raw WebSockets. The function is invoked only when there is activity to react to.
Docs: https://fanout.io/docs/devguide.html#custom-websocket-api
WebSocket-over-HTTP protocol: http://pushpin.org/docs/protocols/websocket-over-http/
Python helper library: https://github.com/fanout/python-faas-grip
AWS Lambda/Azure Functions/GCP Functions don't support web-socket protocol. So it's normal to use third-party services for this purpose.
In additional to comments above I can propose Ably: https://www.ably.io/ .
It provides api/libraries to handle web-socket without pain.