Is there an easy way to enable TCP connectivity for the default puma rails server?
My use case need is to start my rest api puma server and enable TCP connections as well, so that when I call a specific endpoint and use some TCP service inside the rest api it would keep connection alive.
Is this possible? I am not talking about websockets, but TCP pure sockets.
Related
I am trying to set up rabbitmq cluster within kubernetes. Clients can connect to Rabbitmq using amqp protocol rides on TCP and webclients using websockets. As mentioned in WebSocket support for kubernetes, I need to add websocket services against "nginx.org/websocket-services" annotation for ingress configuration. In this case rabbitmq acts as both websocket and non-websocket service.
Will the configuration work for amqp clients loadbalancing if I give rabbitmq service name against "nginx.org/websocket-services" ?
In short, can a service be both non-ws and ws at sametime?
EDIT [ 05-02-2018 ]
It seems there is a different flow for TCP loabalancing. I implemented that. Atleast the routing part is happening but I am not sure about load-balancing of TCP, I need to debug further on that part.
And there is one more reference for websocket loadbalancing and seems to say "No special configuration required".
Kiran
I'm trying to load balance TCP connections over multiple backend servers via Apache Camel and Netty.
I want to make each connection to the backend mapped to each connection to Camel. Something like this:
Client connects to Camel.
Camel selects a backend server and connects to it.
Client sends something to Camel.
Camel sends it to the associated backend server.
Backend server replies to Camel.
Camel sends it back to client.
...
My protocol is stateful and the connection between client and Camel will stay open. I also need messages starting from backend and going to client.
So far, so good. This is working quite nice.
My problem starts when I connect a new client that goes to the same backend server, it looks like Camel reuses the connection that is already open, for the backend server it looks like the first client sent the message, it doesn't receive a new connection request.
I've looked at Apache Camel Netty Component documentation and didn't find anything to configure this behaviour.
Is it possible to do this?
Sidenote: I'm using Camel because I need to inspect the messages in the protocol to select a backend server, i.e. I need a custom loadbalancing strategy. The problem occurs using any loadbalancing strategy provided by Camel, so it's not related to my code.
Camel has a sticky loadbalancer, you just need to setup an expression to tell camel to decide which object hashcode it need to be use.
from("direct:start").loadBalance().
sticky(header("source")).to("mock:x", "mock:y", "mock:z");
i'm having a problem with my app, on a certain situation.
We have a java server with jetty webserver embedded, and an air app on the client side.
It is working properly but on a single situation of a certain customer.
They have a private network that is not administrated by them (and has little chances of being changed as request). So, the only port they allow are 80 and 443.
The communications between the server and the client are through websockets and http.
The "online" check is made through http and, then, we use websockets to notify the client in order to start communication between them.
The thing is, in this situation, the "online" state works properly and any communication send by the client (forced), as it goes through http, gets to the server but, when the server communicates with the client, using websockets, it doesn't work.
We are using wireshark to check the communications: On a working setup, when the client app starts, a websocket is shown on wireshark, on the server side (registering the client on the server). And, after that, websockets that are only used from server to the client, don't show also.
What can be the problem? The port 80? (the same happens with 443 on that network).
Can it be a proxy/firewall that are blocking ws:// messages?
I've read somewhere that wss:// (encripted websockets) would work?
Thanks for your help.
Edit, so, I tried with https and wss communication and the same thing happens.. no websocket is set between the client and server (registering the client on the server).
This situation is happening for http on the customer network. On my test network, it works on http/ws but not with https/wss..
There are many firewalls and gateways out "in the wild" that do not understand the whole WebSocket HTTP/1.1 GET -> UPGRADE -> WebSocket mechanism.
There are several broken firewall implementations will attempt to interpret the WebSocket framing as improper content for HTTP/1.1 (which is a bad reading of the HTTP/1.1 spec) and start to muck with it.
The types of firewalls that inspect/filter/analyze the request/response contents are the ones that seem most susceptible.
I would check that the hardware (or software) that they are using to firewall their network is both compliant and upgraded to support WebSocket RFC-6455.
At the moment I have an existing application which basically consists of a desktop GUI and a TCP server. The client connects to the server, and the server notifies the client if something interesting happens.
Now I'm supposed to replace the desktop GUI by a web GUI, and I'm wondering if I have to rewrite the server to send http packets instead of tcp packets or if I can somehow use some sort of proxy to grab the tcp packets and forward them to the web client?
Do I need some sort of comet server?
If you can make your client ask something like "Whats new pal?" to your server from time to time you can start implementing HTTP server emulator over TCP - its fun and easy process. And you could have any web based GUI.
You can just add to your TCP responds Http headers - itll probably do=)
So I mean HTTP is just a TCP with some headers like shown in here.
You should probably install fiddler and monitor some http requests/ responses you normally do on the web and you'll get how to turn your TCP server into http emulator=)
If you want keep sockets based approche use flash (there is some socket api) or silverlight (there is socket API and you can go for NetTcpBinding or Duplexbinding something like that - it would provide you with ability to receive messages from server when server wants you to receive them (server pushes messages))
So probably you should tall us which back end you plan to use so we could recomend to you something more usefull.
I have web application that runs on Tomcat (and gets HTTP requests) and some other backend standalone application that gets only TCP. For some reasons, I can use outside only port 8080. So, I need to get all TCP requests (from outside) to port 8080 and forward HTTP ones to web application on Tomcat and all TCP pure requests (that are not HTTP) - to standalone application. Internal forwarding could be done to any port, e.g. 8181 on Tomcat and 8282 on standalone application. Is it possible to setup such configuration? How it could be done?
Thanks in advance.
TCP and HTTP are protocols in different networking stack layer. If you want to use some application to filter HTTP requests, your application should deal with Application-Layer information, not Network-Layer(like TCP/UDP).
I don't see how this can be possible generally. You could look packet-by-packet, but the middle of an http body can be arbitary so you can't just look at the data of each packet
If any particular client will send you either http or general TCP but not both, can you do this by source-IP address? Do you know the addresses of either the servers that will send you http requests or the ones that will send you TCP requests?
If you don't know the source IPs, you could heuristically look at the first packet from some previously unknown IP and see if it looks like http, then tag that address as containing http traffic.
What is the content/format ot the TCP communication? Is there any pattern you can detect in that?
Y
Perhaps you could do something like this using iptables + L7 filter. Of course this will only work if you run Linux on your box. Also I don't know how recently l7 filter project has been updated.
Java servlet technology is not limited to Http. The servlet interface lets you read in the incoming input stream via ServletRequest.getInputStream(). So you can create an implementation of Servlet interface and map it in web.xml and you are all set to receive any TCP traffic.
Once you have the read the input stream to sniff the content you will want to forward HTTP requests to an HttpServlet. To do this you will need to make sure that the input stream you pass on is positioned at the very beginning of the input.
EDIT: On reading your question once again, I noticed that you don't plan to expose the Tomcat directly on external port as I originally thought. If you are willing to make the tomcat listen on the external port, you can try the approach described above