Connecting to a Socket.IO server running in Node-Red on IBM Bluemix - socket.io

I've set up a Node-Red instance on IBM Cloud with a Socket.IO server using node-red-contrib-socketio.
I was able to subscribe to events on port 3000 on my local host fine but I'm having difficulty doing the same with the Node-Red instance on IBM Cloud.
According to my client console I seem to be able to connect but get no response using the following URL: ws://MYAPP.eu-gb.mybluemix.net/red:3000/socket.io/?EIO=3&transport=websocket Is this correct or should I be using something else like ws://MYAPP.eu-gb.mybluemix.net:3000/socket.io/?EIO=3&transport=websocket ?
Is any further configuration required in IBM Cloud to enable the connection?
If I need to authenticate within the URL I pass to the server is there a particular way that string should be structured?
Many thanks,

This will not work on Bluemix.
The Bluemix router only forwards external traffic on ports 80 and 443 (http/https) to apps.
But the app may not be actually listening on those ports (The port to listen on is passed in to the application on start up in a environment variable).
You can not just pick an arbitrary ports and listen on.

Related

Cloud Foundry container-to-container networking via https

We have two applications running on ibm cloud cloud foundry (appA and appB).
appA is accessing appB over a container-to-container networking while appB is also available externally over a Gorouter route.
The thing is that while it is http-8080 our app exposes - all is good.
Now we have to do container-to-container networking over https.
We configured the app to expose https-8080. 8080 is used as https://docs.cloudfoundry.org/devguide/custom-ports.html states that:
By default, apps only receive requests on port 8080 for both HTTP and TCP routing,
and so must be configured, or hardcoded, to listen on this port
container-to-container networking works as expected now using https.
But we are no longer able to use the appB over the external Gorouter route.
What is the best way to have it all up and running as we expect?
There isn't a good answer to this question, at least at the time I write this.
You do have a couple options though:
Manually set up HTTPS for the internal route. To do this, you would need to use the instructions for your application/server of choice to configure HTTPS. Then use whatever functionality your buildpack provides to inject this confirmation into the application container. This would also require you to bundle and push TLS certs with your application. The platform isn't going to provide you TLS certs if you take this option.
The trick to making both the internal and public route work is that you need your application to listen on both port 8080 and the port you choose for your HTTPS traffic. As long as you continue taking HTTP traffic on port 8080, then your public routes should keep working.
If you want a quick, but not ideal solution you can use port 61001. For newer versions of Cloud Foundry, this port is used by Envoy to accept traffic to your app over HTTPS. Envoy then proxies the request to your app via HTTP over port 8080. You can use this port for your container to container traffic as well, however the configured subject name on the TLS cert won't match your route.
Here's an example of what the subject name will look like.
subject: OU=organization:639f74aa-5d97-4a47-a6b3-e9c2613729d8 + OU=space:10180e2b-33b9-44ee-9f8f-da96da17ac1a + OU=app:10a4752e-be17-41f5-bfb2-d858d49165f2; CN=b7520259-6428-4a52-60d4-5f25
Because it's using this format, you would need to have your clients ignore certificate subject name match errors (not ideal as that weakens HTTPS), or perhaps create a custom hostname matcher.
For what it's worth, I don't think you want or need to change the port. That is typically used if your application is not flexible and unable to listen on port 8080. It changes the port for inbound traffic. Since you're only using C2C networking, you don't need that option.
What you want, from what I understand, is that you want HTTPS for C2C traffic. In that case, the public traffic doesn't matter. It can still go through Gorouter to port 8080. For your container-to-container traffic, you can pick any port you want. You just need to make sure the port you choose has network policy set to allow that traffic (by default all C2C traffic is blocked). Once the network policy is set, you can connect directly over whatever port you designate.

Can we host a host websocket server in cloud as proxy/relay server to redirect websocket traffic from local network

[This post has been updated with a possible approach, which is added to the bottom]
I am trying to create a web socket connection between two devices((A). chrome in different computer and (B) a raspberry pi) in different networks. Thus, i can send video data over websockets. However, I cannot port forward the network of my router to expose my local IP to the network, thus, I can't send the data right away.
Figure below explains the architechture.
Thus ,I am trying to implement a logic so that Device A websockets the public ws of the cloud while, the cloud actually gets the data from Device B.So Device A websockets device B indirectly.
Device A<==>Cloud Server<==>Device B
The cloud could be something like a proxy or a relay websocket server.
The video feed needs to be sent in real time,
Please suggest how can i proceed with it.
Additional note, i have acquired an instance of digitalocean as VPS, following the blog Accessing home services from anywhere, without port forwarding! but not sure how to proceed.
Update(11th Nov,2019):
I am planning to use a websocket server on DigitalOcean instance(droplet),which would be listening to my local IP/port of my raspberry pi.And this VPS would act as a websocket server,which would redirect the traffic.
However, I am unsure how to use the same.And need your kind suggestions.

How to listen to a TCP port to detect changes in the server?

I'm working on mac os x. I'm trying to build a cocoa app working on a storage server (similar to Dropbox) that does something whenever a file is added,removed..I have already a client app installed on the mac that shows all the files stored on the server and I need to listen to the port that the server is using to send changes notification to the app. I've started following some tutorials for Sockets but I get "Address already in use".
The Question: are sockets the only way to listen to a port and if yes is there a way to build a socket to listen to an already existing server/client connection?
If a process is already listening on a port then no other process can bind(2) to that port. Alternatives would include to have a proxy listen on that port that would deal with events and then pass them on elsewhere (the client app may not play well with this), or to use firewall rules to duplicate the packets to some other port that your app would then listen on, or maybe the client application issues notifications that then can be acted on.
https://github.com/thrig/lognots
Is one way to inspect the notifications available.
Remember that listening on a port is how you prepare to receive incoming connections. It is not necessary to receive data — once a connection is established, data can flow in both directions! It is almost never appropriate for a client application to listen on a port; that's usually only appropriate for server applications.
With that in mind: Your client application should connect to a port on the server, and the server will send data to the client as appropriate.

Connecting to external broker through restricted network using Paho Java Client

My client is using a restricted network i.e it's behind a firewall which permits requests to only 443 port. So it does not allow the client to connect to any other port that my mqtt broker is running on.
Is there any way to connect to target broker running on random port like 12000 with such network restrictions using Paho java client?
I think I will have to start a proxy which will route mqtt connect request to target ip and port but I am not sure how to do that.
Please help me out and let me know how can I achieve this
You should be able to start a broker listening on any port you want. How you do this will vary depending on which broker you are using.
A second option may be connecting to the broker using MQTT over Websockets. This would allow you to use the existing HTTP proxy on the network, but I'm not aware of any client libraries (except the Paho Javascript client for use in web pages) that currently support this.

Socks 4 Bind Request Explanation

i was reading this topic
http://ftp.icm.edu.pl/packages/socks/socks4/SOCKS4.protocol
and what im trying to do is:
i have a client/server application, what im trying to do is to use socks 4 BIND request to bind my server to a remote socks server, and make the clients connect to that socks server and the socks server will make them connect to my server (at least thats how i understand socks BIND request)
but i don't fully understand it (my English is kinda bad), what im asking is, is it possible to do so when i dunno any of the remote IPs of the clients? since the server's BIND request package must contain the address of the remote client and i dont really have than since the clients are from unknown users retrieving status info from my server (or can i use 0 for INANY_ADDR) ?
What you are asking for is not possible with SOCKS, nor is it meant for that purpose. Read the spec again more carefully. The BIND command is meant for use with multi-connection protocols (like FTP), where a primary connection is used to communicate between a client and a server, and BIND facilitates situations where the server needs to connect a secondary connection to the client after the client tells the server where to connect. In that situation, the client would issue a BIND command to SOCKS telling it the server's IP/Port so it only accepts that connection, then send the resulting SOCKS listening IP/Port to the server to connect to.
What you are asking for is better served by using a router with Port Forwarding rules defined. Then you can open a listening port on the router that accepts any inbound connection and forwards it to your app's listening IP/Port. Most modern routers support uPNP (Universal Plug-N-Play) so you can configure the forwarding rules programmably instead of requiring admin access to the router's configuration software.

Resources