We Keep Coding

Where does all data send with nodejs method socket.write?

Good day! Where does all data send when nodejs method socket.write is called? I understand that socket runs of the server side for each client. But where exactly does data go? to client? On official nodejs documentanion there is no info about destination. Thank you for response.

You cannot successfully write to a socket unless you (or some part of your nodejs software) first connects it to some other socket somewhere.
A socket server listens for connection requests, and then accepts them as they arrive. (When you use node express to make a web server, express handles this for you.) A client connects to a socket server. Once the pair of sockets are connected, data you write into one of the sockets causes a data event on the other one.
The two sockets may be on different machines in different locations. That's the miracle of global networking.
So where does data you write go? To the other socket in the pair.
If you are using datagrams (not connections) it's slightly different. The data you write contains the destination address. But you probably are not using databgrams. If you are, you are probably using a protocol stack like RTSP or UDP instead of TCP.

connect to C# server from javascript

Is it possible to create a javascript program that connect to a simple C# server using a simple socket and not a WebSocket.
can you help me with a sample.

There is no standard way to make a TCP connection from Javascript code running in a web browser. (See the answer by #Johannes Hahn)
To communicate between your client and server, consider Microsoft's SignalR library. It is designed to allow a Javascript program, running in the browser, to communicate with a C# server. SignalR will use websockets; however, it will continue to work if websockets are not available by falling back to other transports. You can also specify transports, if you need to prevent it from attempting to use websockets.
SignalR connection starts as HTTP, and is then promoted to a WebSocket connection if it is available. WebSocket is the ideal transport for SignalR, since it makes the most efficient use of server memory, has the lowest latency, and has the most underlying features (such as full duplex communication between client and server), but it also has the most stringent requirements: WebSocket requires the server to be using Windows Server 2012 or Windows 8, and .NET Framework 4.5. If these requirements are not met, SignalR will attempt to use other transports to make its connections.
Also, be aware that if your Javascript is not running in a web browser, you can make regular network connections. For example, a Javascript application running on Node.js.

It seems that at least Firefox is supposed to know about socket, see https://developer.mozilla.org/en-US/docs/Web/API/TCP_Socket_API. But (taken from the same source) TCP or UDP sockets are not part of any standard and therefore likely either unsupported or completely different in other browsers.

In principle no. For security reasons browsers only allow a limited set of protocols. Chrome has a socket API, but that is not standard - https://developer.chrome.com/apps/sockets_tcp. There are solutions which use a WebSocket connection to a server which then establishes a TCP socket connection, e.g. https://github.com/kanaka/websockify, http://artemyankov.com/tcp-client-for-browsers/, so if you can't add WebSocket directly to the server you may want to check these out.

Trouble sending TCP message with Socket.io

So I'm attempting to send a TCP message to a device plugged into my computer, with an IP address of xxx.xxx.1.32 over port 9999 with Socket.io. The client successfully connects to the TCP server running on the device, but I can't seem to send any actual message to it. Here is the output I'm getting from the device:
And my client-side code:
<script src = "https://cdn.socket.io/socket.io-1.2.1.js"></script>
<script>
var socket = io('http://xxx.xxx.1.32:9999');
socket.on('connect', function() {
socket.send('GPIO,00,0');
socket.emit('GPIO,00,0');
socket.on('message', function (msg) {
alert(msg);
});
});
</script>
It periodically receives the same messages detailed in the first picture (which makes sense since the Connection: field is set to keep alive), but it never seems to send the messages, even after first making the connection. Any ideas as to what is going wrong?

Socket.IO doesn't do plain TCP sockets as that is not possible to do in the browser. Instead it uses WebSockets which require a handshake built on top of HTTP (or alternatively some other HTTP-based fallbacks). If you want to talk to your custom device with Socket.IO you'll have to implement their entire protocol by hand.
If you can't or don't want to run node.js on your device, it might be best to forget Socket.IO and just use plain WebSockets. Or even implement a proxy server on a full-fledged computer that can proxy things over plain TCP.

Connect two socket.io clients together (Establish a socket to socket, cross browser connection)

I'd like to know if there's any way to establish a P2P connection between two browsers using socket.io-client (but I'm willing to use anything else that may do the trick).
Both browsers are currently connected to a node.js app serving HTTP requests with Express, which stores both clients's IP addresses (and ports when running locally). What I'd like to do is add a third connection that links both clients (let's call them A and B) directly, so that messages/data will go straight from one client to another, without transiting through the node.js server.
Is that feasible? If so, how?
So far, I've tried connecting the two clients (let's call them A and B) with the following code:
Client A:
A_to_server_socket = io();
A_to_server_socket.on('p2p', function(address_B){
A_to_B_socket = io(address_B); // Instantiates a new socket
A_to_B_socket.on('connect', function() {
console.log('Connected!');
});
});
I'm not sure about the code for client B. However I've tried:
repeat the above code for B, using B's own address (to override the default of connecting to the server)
repeat the above code for B, this time using A's address
having B_to_server_socket listen for a new connect event
However regardless of B's code, when running A's code I'm confronted with a "Cross-Origin Request blocked" error on Firefox, or "Failed to load resource: net::ERR_CONNECTION_REFUSED" followed by "net::ERR_CONNECTION_REFUSED" on Chrome.
Any hints towards a solution, or insights for better understanding the problem and how sockets work would be most welcome.

I'll try to summarize my comments into an answer.
In TCP, a connection is made when one endpoint A connects to another endpoint B. To connect to endpoint B, that host must be "listening" for incoming connections originating from other hosts. In a typical web request, the browser establishes a TCP connection to the web server and this works because the web server is listening for incoming requests on a specific port and when one of those requests comes in, it accepts the incoming request to establish an active TCP connection. So, you must have one side initiating the request and another side listening for the request.
For various security reasons, browsers themselves don't "listen" for incoming connections so you can't connect directly to them. They only allow you to connect outbound to some other listening agent on the internet. So, if a browser never listens for an incoming webSocket connection, then you can't establish a true peer-to-peer (e.g. browser-to-browser) webSocket connection.
Furthermore, TCP is designed so that you can't have two browsers both connect to a common server and then somehow have that server connect up their pipelines such that the two browser are now just wired directly to each other. TCP just doesn't work that way. It is possible to have an agent in the middle forwarding packets from one client to another via a separate connection to each (that's how Chat applications generally work), but the agent in the middle can't simply plug the two TCP connections together such that the packets go directly from one client to the other (and no longer go through the server) as a fireman would connect two firehoses. TCP just doens't work that way. It might be possible to have some complicated scheme that involved rewriting packet headers to a packet sent from endPoint A was forwarded to endPoint B and looked like it came from the server instead, but that still involves the server as the middleman or proxy.
The usual way to solve this problem is to just let each browser connect to a common server and have the server act as the middleman or traffic cop, forwarding packets from one browser to another.
Existing P2P applications (outside of browsers) work by having each client actually listen for incoming connections (act like a server) so that another client can connect directly to them. P2P itself is more complicated than this because one needs to have a means of discovering an IP address to connect to (since clients typically aren't in DNS) and often there are firewalls in the way that need some cooperation between the two ends in order to make the firewall allow the incoming connection. But, alas, this capability of listening for an incoming connection is not something a browser from plain javascript will allow you to do.

There is no something like "connection between two browsers using socket.io-client."
But there is "Both browsers are connected to a node.js app serving HTTP requests with Express, which keeps track of both clients's IP addresses (and ports when running locally)."
If you want to have P2P connection between two browser, following may be a way to do so.
when you get client A connection, join to a room "P2P"
when you get client B connection, join to a room "P2P"
to exchange between client A and client B, use
socket.broadcast.to('P2P').emit("message", "Good Morning");
Hope this may help.

Javascript client C++ server game

I have a question which path should I follow.
I want to develop real time online game via webbrowsers.
I would want to write game server using C++ with TCP sockets listening. The client side game will be written in javascript. The only problem I dont know how to communicate javascript with c++ server using TCP sockets. I have considered using Socket.IO but as far as I know this library does not have option to just connect to real TCP server, push bytes through and read incoming ones. Instead I would need to use some wrapper like Node.JS server which I want to avoid.
Anyone could guide me which path I should take?

You could make your game server itself an HTTP server. For the most part it could just serve up your static files, but when it received a WebSocket upgrade request, it could handle that however it desired.

You should take a look to websockify:
websockyfy is a WebSocket to TCP proxy/bridge. This allows a browser
to connect to any application/server/service. Implementations in
Python, C, Node.js and Ruby.