WebSockets: What do you want?

Thanks for the comments Rushino. Although I don't use C# myself, you've set me to thinking.

From what I gather, free educational-use Microsoft tools are used in schools quite a bit and C# is one of the languages students use. So, there are a lot of people who have learned it and are used to it. The HLL framework was written with the idea that people can build app components in any language. I have a free C# compiler on my dev machine which I guess still works (although I've updated .NET since I got it ... so long ago). I'll put doing a short demo on my to-do list.

You can use visual studio 2012 express.Its free! You certainly dont need to buy the pro one plus the express enable commercial use.

You can use visual studio 2012 express.Its free! You certainly dont need to buy the pro one plus the express enable commercial use.

Yes, now I remember. That's what I have. Maybe I should download again since it's been so long. Might be some updates.

C# is one of the most popular language and really easy to use. The framework is an huge advantage for server logic so that basically why i think it rock. But well everyone have their own tastes and opinion. I changed the way i work i now go for a DRY and KISS approaxh and that enough for me.

Being a tool builder and with my love for pushing beyond the cutting edge might give me a different perspective. But you've reminded me that is exactly what I have to keep in mind. I actually know this, but when focused on things I'm doing, I'm also focused on my own development approach. In the end, a "product" must appeal to its users and their preferences. You're not the first to mention that you use C# in app development.

I'm hoping a lot of this won't take too long. I've done the core of the really big work already. WebSocket server in hand, it's now down to features aimed to support game development. So ... not being in the top spot on my to-do list shouldn't be terribly important. I think my to-do for language support looks like this:

1: XML supporting arbitrary command language

2. JavaScript for server logic

3. C/C++/C# extensions

Unless something pops-up and takes over my time, I should have XML looking pretty good by Monday. "Arbitrary command language" means a game developer can decide on their own set of messages. Note: JSON isn't on the list because it's supported in the browser and can be used anywhere, messages in the XML for example.

JavaScript ... I've had this on the list for a long time and it's about time I did something about it. Up to now, all my server-side handlers have been written in Java. The success of Node.js for example, is directly related to the fact that there are a lot of people who know how to program in JavaScript who want to use this sort of technology.

C/C++/C# can all be addressed with Java's Native Interface (JNI).

I might as well go ahead and promote HLL XML processing a little. I'm going to adapt something that I developed in the framework. The idea was that the HLL development system supports a very powerful way to "configure" applications. I have quotes around "configure" just to add emphasis. Configuration becomes a more important part of developing end applications ... reuse of components. Kind of a next step beyond SOA, might be one way to put it.

I think it's ripe for supporting development the way C2 does it, more or less. I'll see if I have time for a simple HTML interface for creating back-end logic this weekend. Not sure I'll have time for that step by Monday, but ... maybe a very simple version.

I don't see why no ones using Node-Webkit.

You could introduce a npm package via the plugin sdk, and write all your server side logic in Construct.

I don't see why no ones using Node-Webkit.

You could introduce a npm package via the plugin sdk, and write all your server side logic in Construct.

Interesting. I'm going to try to imagine how it might be useful in my work. It's not WebSockets though ... just to make sure we're on the same page; and the only page I read was the C2 intro. scirra.com/manual/162/node-webkit

It says it uses Ajax (asynchronous http) to read files from the application folder.

Actually though ... I can set up the HLL WebSocket server to get files as well. .... OK, brain cooking ... I wonder if it could be interesting to also give the WebSocket server the ability to fetch files from your C2 subscription application folders? ....

Well ... What would you like to do with it?

Well it really wont have a lot to do with the Node-webkit plug, although you would want it to do some file work perhaps.

What you would really want to do is use the Node.js side of it.

https://github.com/rogerwang/node-webkit

And have C2 be able to make both the server, and the client.

I can't figure out whether it's way out of date old, days before Chrome, Mozilla etc. etc all have HTML 5 built in, or maybe just because Node.js is JS. It could be the latter. Despite the fact that Node.js has the advantage of being in JS and thus finds an audience in front-end developers, it also has the disadvantage of being in JS; which limits its capabilities.

I think I'm going to be ok giving developers the opportunity to write back-end application logic in JS; but then I'll also have the advantage of execution within Java running on the server ... so, I don't have to work around the limitations. They won't exist.

I'm not of the Node.js world, so this is taking a bit of looking around to catch on. NPM is a JavaScript helper library ... how it's described on a page I just found listing what it has. npmjs.org

Obviously, I haven't tried out any of the packages. But it's an interesting idea. Some of the things mentioned ... I just thought I'd cover by having it standard kit in the game support server side; like registration, and there will definitely be messages passed back and forth. In addition, there needs to be a mechanism for pairing players in multiplayer games. I don't expect the developer to need to build that from scratch, but they will be able to customize in some way I expect.

I'm a great believer in examples and tutorials as well, and hope to have the time to do that ... and hope people who use it will write how tos. Maybe that should be part of the deal with early free adoption - the Alpha group.

I should be making a list of what needs to be supported as an outgrowth of this thread. I tend to do all that in my head when I'm working alone. I think you mentioned reading files. You can certainly send files via WebSockets or can fetch them using Ajax. So, I'm not sure what you need other than the WebSocket message or Ajax code. Would it be sufficient to provide that in a "package", or do you have something fancier in mind?

The first thing I would look out for is security. Its all very open, and very hackable as well. There are already several npm's for different web auth's Facebook, Twitter, Google, etc. Those or others could be used to layer some defense, and would be good experience for a starter.

There are also many different npm's for making connections(Websockets etc), as well as databases.

I should say I have no idea how the file system would or even need to fit into that, as well as no idea how well Node-Webkit would work for a server.

Also working the packages in with C2's sdk will probably be an issue. In fact I'd wager it would require rewriting some to suit C2.

Then you also have to take into account the third party nature of all that, don't want to step on anybodies toes.

For anything regarding payment i would suggest Clay.IO i tested it.. the downside is that you have to pay 20% to them for each transaction and have to lets the user login. So if you have your own login (like i have) this is a bit of a problem but not that much. This is nice cause you don't have to handle stuff like rating, achievements, virtual items or packages, etc. You could even make use of multiplayer rooms and stuff or select the only stuff you need.

Like newt, your server must be secure. Its hard. I won't get into much details but there are basics stuff you need to know.

• Login systems. Your password must be hashed with a salt also avoid giving too much infos.. like username doesn't exist or stuff like this. This can lead to a lots of problems.
• Server flooding. You need some kind of protection against how many queries your users can send to the server. You don't want your server to hang.
• Queries validation. This is very important! I suggest implementing some kind of STATE check on the session side. Player can't send X if not in state Y.
• Queries auth token. Depend on your server.. mine got this already implemented, the server know which ones send queries based on a kind of session system. So if A send 123 then the server know its A and not B. But if you don't have such system you need to make your own. Basically, once your logged on the server send a token (hashed string) to the client and each time the client send a new query (to know he is logged in) you include this token in the query.
• Enable SSL. Your must encrypt your stuff.
• You also need to handle what happen if the query is invalid ? and question like thoses.
• Also, NEVER put any kind of client logic except drawing/display logic. This is a big mistake.. everyone can see what you send and change the internal of your javascript.

Like i said this is basic stuff you have to take care right now.

WebSockets are already pretty secure. You have to go through a "handshake" process to make a connection. Then that's your connection. Hackability is more of a systems issue. I've seen pretty good coverage on standard packages and routers, even giving specific information when someone tries to get in in the wrong way. Other things are application specific, such as when you take user input in forms to stash in a database ... easily dealt with. I've been all through this, in gory detail, while doing commercial webshops.

"Server flooding" sounds like a more innocent version of "denial of service" attacks. Yes, you'd definitely want to provide enough server power to run whatever is supposed to run. That might be a more reasonable description for a solution, rather than restricting legitimate traffic. It's also something to be considered on the economic side of things .. how much power is needed ... what's it going to cost to have big enough, or as many servers as needed?

Free WebSocket JavaScript Code and Tutorial

By Roger F. Gay

highlevellogic.blogspot.se/2013/09/free-websocket-javascript-code-and.html