this is my first post here so I hope I do well.
So, for a school project I'm handling our game's networking and we have chosen to create a multiplayer fighting game where users are able to use their phones as controllers. Originally, we were going to use phone mobile browsers and so I had some crazy Websocket server, TCP server combination going on.
Since then, we have decided to use a Unity app on the phone instead which has removed the need for the Websocket server. Before I explain the steps, these are two Github gists of the relevant code snippets that you can open in other tabs in order for this to be a bit easier to follow:
NodeJS TCP Server: https://gist.github.com/JesseLeitch/dce3f51eea893ea5872c
Unity TCP Client: https://gist.github.com/JesseLeitch/59212d34a6fad41a2efc
Now, my problem:
I will walk through the process here:
1) I start up my NodeJS TCP server on my laptop.
2) I start up a Unity game, receiving a message from the server that it has connected.
3) My team mate starts up a Unity "game"(it's our controller) on his laptop that connects to the server with a successful connection message once again from the server.
4) My friend presses a button on the controller.
5) The button sends a message to the server. For example, "Jump".
6) Here is where my problem arises. What should happen is the server then sends the message down to the game, the message is processed within the OpenStream function and then it is passed off to a movement script. This is not happening. Nothing is being read in the game and I do not know why.
I know that the writing function is working fine because the console.log on line 14 is outputting properly with his command. What I am unsure of is why the c.write(d) is not seemingly working properly - especially because this worked previously when I was using our previous Game <-> TCP <-> WS <-> Mobile browser set-up.
Any help people can offer is greatly appreciated as I'm stumped and I haven't seemed to find anything relevant in my searching because the server seems to communicate fine except for this issue.
Thanks!
~Camel
Related
I have a node script I'm working on that connects to an IRC channel for twitch.tv and responds to commands, as well as moderates chat lines that are being sent by other users connected.
Currently I open a terminal to the file location and run node app.js to start the IRC connection. But this runs on my mac and I use my PC to play games and watch the chat, so I have to have the Mac next to me to start and stop the IRC chat client app.
I want to move this to a web server where I can log in and start or stop the chat client app from the website, so I don't have to have the Mac next to me all the time.
What would be the best way to go about this?
If you want to see the script I'm working with you can find it here
https://github.com/Jordan4jc/super-fly-twitch-bot
You could create an HTTP server and listen on a port (if you don't mind overkill, express.js could make things easier for you). This server would contain configurations for the URL, authentication, etc. Within the callback that you provide to a URL path, you could close the IRC channels, database connections, and call process.exit(0) once you're confident that you've done everything necessary and you're sure it's what you want.
You can use socket.io as a way to send signals in real time to the application.
I have a production app that uses socket.io (node.js back-end)to distribute messages to all the logged in clients. Many of my users are experiencing disconnections from the socket.io server. The normal use case for a client is to keep the web app open the entire working day. Most of the time on the app in a work day time is spent idle, but the app is still open - until the socket.io connection is lost and then the app kicks them out.
Is there any way I can make the connection more reliable so my users are not constantly losing their connection to the socket.io server?
It appears that all we can do here is give you some debugging advice so that you might learn more about what is causing the problem. So, here's a list of things to look into.
Make sure that socket.io is configured for automatic reconnect. In the latest versions of socket.io, auto-reconnect defaults to on, but you may need to verify that no piece of code is turning it off.
Make sure the client is not going to sleep such that all network connections will become inactive get disconnected.
In a working client (before it has disconnected), use the Chrome debugger, Network tab, webSockets sub-tab to verify that you can see regular ping messages going between client and server. You will have to open the debug window, get to the network tab and then refresh your web page with that debug window open to start to see the network activity. You should see a funky looking URL that has ?EIO=3&transport=websocket&sid=xxxxxxxxxxxx in it. Click on that. Then click on the "Frames" sub-tag. At that point, you can watch individual websocket packets being sent. You should see tiny packets with length 1 every once in a while (these are the ping and pong keep-alive packets). There's a sample screen shot below that shows what you're looking for. If you aren't seeing these keep-alive packets, then you need to resolve why they aren't there (likely some socket.io configuration or version issue).
Since you mentioned that you can reproduce the situation, one thing you want to know is how is the socket getting closed (client-end initiated or server-end initiated). One way to gather info on this is to install a network analyzer on your client so you can literally watch every packet that goes over the network to/from your client. There are many different analyzers and many are free. I personally have used Fiddler, but I regularly hear people talking about WireShark. What you want to see is exactly what happens on the network when the client loses its connection. Does the client decide to send a close socket packet? Does the client receive a close socket packet from someone? What happens on the network at the time the connection is lost.
webSocket network view in Chrome Debugger
The most likely cause is one end closing a WebSocket due to inactivity. This is commonly done by load balancers, but there may be other culprits. The fix for this is to simply send a message every so often (I use 30 seconds, but depending on the issue you may be able to go higher) to every client. This will prevent it from appearing to be inactive and thus getting closed.
I've got problem connecting Flash client to Node.js server.
Short story:
For a first time I'm building a Node.js server that should be used by both web client (WebSocket) as well as a Flash client (Socket). The web client, of course, works like a charm, but I can't get over the Flash one. I get SECURITY_ERROR. After a day of research I think it's because of the policy file not being loaded. Ideas (primus on top of engine.io) ?
Long story:
I'm using Primus as I thought I'll need it because I have both web sockets and flash sockets to handle. Not sure if this is accurate? :)
I'm using Engine.io as a 'transformer/transporter' - the main framework that the layer uses. I won't discuss the standard web client (using Chrome and primus-client), as it's easy to setup.
I'm using simple and standard Sockets in AS3:
_socket = new Socket();
_socket.addEventListener(Event.CONNECT, onSocketConnect);
//...
_socket.addEventListener(SecurityErrorEvent.SECURITY_ERROR, onSecurityError);
_socket.addEventListener(IOErrorEvent.IO_ERROR, onIOError);
_socket.connect('localhost', '1337);
When building it within Flash IDE, it goes to the onSocketConnect function, but if I try to write anything to the socked - I get disconnected. If I run this from the web browser, I get into the onSecurityError method.
I must say that I don't get any traces in the node console!
primus.on('connection', function connection(spark) {
console.log('new connection'); // never gets logged!
As I know, security error is thrown when there is error with the policy file, so I started searching for a solution for that.
I've read a lot of things online, and most common solution was simple usage of socket.io and so called FlashSocket.IO. I tried implementing it, but it's so old, that some of the code is a kind of missing and I finally got some errors from the hurlant library - I couldn't get it working.
I also saw some node package called policy, which runs separate server to server the policy file.
I tried adding a transport array with flashsocket in it - no change. I also can't understand why all of the samples are using transports - I've searched and both index.js and primus.js are using transport (why there are two separate files, Jesus?!)
I could try using only engine.io without primus, but I don't know if this would be of any help. All the posts and samples I've found are pretty old - please help me with any up to date solution or at least some explanation what needs to be done - seems like a whole new universe to me :)
Thanks in advance!
Edit:
Thanks to the The_asMan, I figured out it has something to do with the handshake. I've tried this simple example (despite the fact it's so old) - it worked perfectly for the Flash client! Of course I cannot connect web sockets to it, as the handshake is not proper - it has some kind of protocol for it.
So I guess I just have to understand how to get the <policy-file-request/> in node - I'll be able to return the policy file. But I don't know how to get it - I don't receive any kind of data nor connect handler...
You have a cross domain policy issue.
I answered it all here.
AS3 - Flash/AIR Socket Communication writeUTFBytes only works once
just an idea:
On some operating systems, flush() is called automatically between execution frames, but on other operating systems, such as Windows, the data is never sent unless you call flush() explicitly. To ensure your application behaves reliably across all operating systems, it is a good practice to call the flush() method after writing each message (or related group of data) to the socket.
I am writing a multiplayer real time game for the browser with the server as a master instance and the clients as input devices and slaves to show the graphics.
I have to send out changes in the game world very often and very fast and it doesn't matter if some of the data sometimes gets lost on the way because a couple of milliseconds later there will be the next update anyway.
Right now I am using Socket.io to talk between the server and the clients but this uses TCP which makes the update come in unnecessary late sometimes.
I know that there is WebRTC with data channels where I would be able to send my updates through wit UDP which would be very awesome and exactly what I want. And it even seems to be implemented in Firefox and Chrome already https://stackoverflow.com/a/12864512/63779
What I now need is some Node library which would allow me to use data channels to send my data (for now just JSON strings) with help of UDP to the clients which are browsers. On the browser I would be able to use webkitRTCPeerConnection() but I have no idea how to start something like that on the Node server. Any suggestions? If there is no Node module for that, would it be possible to write something in some other language and just send the data via Unix domain sockets or something?
We are building some installation of a multiplayer game. Our computer (running a node.js server) projects the game on a large screen and the players connect with their mobiles through websockets (html5). We already figured out the client side (no need for animation there, only some buttons inputs), the question is how to connect the game visualization on the server side (either in processing or processing.js) with the clients. In particular:
can the server side javascript, which runs outside of a browser (from the terminal, using node.js) supports canvas-like graphics (eg., using raphael or processing.js) ?
alternatively, how can a processing sketch running on the server machine connect with nodejs?
any other solutions are welcome - thanks!
jonathan
You need three parts here.
clients with buttons, which you already have
a node.js server, which you already have
client with your game running in a browser on your wall.
Both (1) and (3) set up a websocket connection to node.js, and then you have node.js accept player input from (1), which it then sends to (3). The page at (3) should have the sketch running with a JS binding, and have a socket data handling function, so that when the handler function sees data coming from node, it can pass that on into your sketch, which can then update itself according to the input.
You don't need to run the game server-side, just run it client side using Processing.js (I assume your game is in Processing because of the tags you used for the question)