Feature Request: sockets / networking

Monkey Forums/Monkey Programming/Feature Request: sockets / networking

Skn3(Posted 2011) [#1]
I thought it would be good to get a discussion going.

At some point in the coming months I want to have a look at wrapping iOS networking code to use in monkey. I already had a look into this and it seems like it will be an interesting project. Now this isn't something that is uncommon, multiplayer is essential for games these days. I really think monkey could benefit if some consideration was taken on adding support for networking/sockets to the mojo framework.

Naturally html5 sockets are not very well supported but could this not be implemented so that when the browser does not support sockets, simply return null/false/error for the commands. That way at least the game designer can add in a notification to the user to "Please try in a browser that supports sockets".

I think to cover all bases there would need to be a game match-up API and socket API and then let the programmer do the rest. Maybe the html5 match-up service could use something similar to the gnet system. Naturally iOS could default to the gamecenter service...

Something like:
Local matchup := CreateGameFinder()
If FoundGameServer(matchup)
	Print "Found Game Server: "+GameServerName(matchup)
	Local Socket := CreateUDPSocket(GameServerIp(matchup),GameServerPort(matchup))
	SendInt(Socket,5)
	CloseSocket(Socket)
EndIf


It could be made more flexible by adding match-up "drivers" e.g. CreateOpenFeintGameFinder() so that future game services could be added. The CreateGameFinder() would use the default match-up driver which is specific to the target being compiled to...

This is hopefully similar to the design I will follow and I will have to fill in the blanks for platforms as I release to them. I am by no means an expert in most of the platforms so I suspect my efforts will be very slow in development and probably a bit rubbish. The trouble is I can't afford the time to support such a module and I need to partially hard-code this into my engine. So I wont be much use to the community...

What are peoples thoughts on a networking API, how should it work? should it be an official module? What are monkeys plans for such a module?


Tibit(Posted 2011) [#2]
I will very much need this in the upcoming months as well.

However I do not want a gnet system. I have not intention to offend Mark or anyone else, but since I built a network library in BlitzMax I know from experience that having bare socket-functionality is enough.

I don't know how many countless e-mail I got from users who could not get gnet to work, and I myself had problem with it. And I have found that high-level libraries can be nice, they do also limit you a lot.

So I much prefer if monkey implements just the essentials socket functions. SendTo/Recv UDP and for TCP send/recv. The closer to the bare minimum we can get the better performance and usability will networklibraries built upon it be.

My view is this. Yes Monkey NEEDS networking - but only very simple stuff.

Skn3, if Mark does not want to add networking basics to monkey in the foreseeable future then maybe we can work together on this? I can provide an SVN server. I'm happy to share my code public if we do this as some kind of community project.


TeaBoy(Posted 2011) [#3]
Yup, PLEASE :o) Monkey NEEEEEEEEEEEEEEEDS this feature!


Tibit(Posted 2011) [#4]
Just out of curiosity, what are you specifically going to use the networking for?

I'll use it primarily for remote updating of in-game stuff from my server.


FlameDuck(Posted 2011) [#5]
Two things.

1) I agree with Tibit that the game-matching is a bad thing to include in your network, unless you want to foot the bill for the infrastructure. You can always use a third party system if you really need it, and if you depend on (for instance) a PHP/MySQL solution, that's not going to work at all on my Google App Engine/BigTable setup.

2) For the network side of thing, take a look at Twisted. While I realize porting that beast to Monkey would be an astronomical (if not impossible) task, you should definitely be inspired by how it works. I mean a library where writing a (simple) server is 20 lines of code? Yes please. I'll take 2.


Xaron(Posted 2011) [#6]
That would be awesome!

Actually I already started a network module: http://www.monkeycoder.co.nz/Community/posts.php?topic=725

Maybe we could just integrate everything there? I'd like to create some socket communication as well, which won't be available for all targets of course.


Skn3(Posted 2011) [#7]
Hey Tibit I would love to say yes but I am hella busy and I think it would unavoidably eat up time in development. I would be happy to try and contribute some code/knowledge/discussions as I go along but I don't think I could be a founder of the project.

1) I agree with Tibit that the game-matching is a bad thing to include in your network, unless you want to foot the bill for the infrastructure. You can always use a third party system if you really need it, and if you depend on (for instance) a PHP/MySQL solution, that's not going to work at all on my Google App Engine/BigTable setup.


Yeah it would most definitely be a bad idea to rely on a gnet system as the primary game service, however it would be a good solution for html5. As long as there was a flexible way to add new services that is...

Xaron, aside from plans etc have you got anything running with sockets? Would be interesting to see your progress.


Xaron(Posted 2011) [#8]
To be honest my only experience with socket programming is using C++ and Windows. Can't be so different on other platforms though. ;)


MikeHart(Posted 2011) [#9]
If someone is bored, maybe they could create a module for using Pubnub.

Seems that this could be easily ported/imported.

http://www.pubnub.com


Skn3(Posted 2011) [#10]
Well I started having a play around today on my lunch break with html5. I have not done any part of the sockets itself, instead was experimenting with how the data could be handled.

Just playing around for now so its nothing serious! I have been looking at the websockets support:
https://developer.mozilla.org/en/WebSockets/WebSockets_reference/WebSocket#send%28%29

There is not really a sensible way to handle data yet in javascript. There is a ArrayBuffer object in javascript but that has fixed width (you wouldn't be able to mix bytes, ints and floats in one buffer). There is a DataView object but this is not supported very well so finally the solution is to manage the packing into a string.

I had started writing a binary packer but found a nice one already done via the interweb!

sockets.monkey


native/sockets.html.js



Tibit(Posted 2011) [#11]
Cool!

Good start :)

Is the packing done using some specific standard?

Since the only thing to do next then is to be able to unpack the data (and pack it) on all other platforms. I know .Net has built-in functions for all those toByte toInt and so on.

It seems to me at first look that packing into a byteArray (using the same means) would be better than using strings since they are often 16bit and that can mean wierdness and inconsitencies depending on language.

However with that said, I have some awesome bitPacking functions from TNet in BlitzMax that I should thank Koriolis for.

And converting these to Monkey would mean that if we ONLY get string-sending to work across all platforms then we will be able to pack anything (int,float,and so on) into that string if that makes sense?

It is the String to ByteArray and ByteArray to String conversions that should be the hardest part of that?

Also another note, html5 sockets are like awesome, however unlike other sockets they require a "initialization" procedure. This needs to be taken into account on the serverside of things as well.

I was also thinking that it might become popular to have the server in PHP, so maybe we should consider that as well? The problem there is only that Monkey does not built to php yet ;)


Skn3(Posted 2011) [#12]
The packing is done using standards as far as I can see. The library supports little/big endian and also specific variable types eg short, long, float, etc

It would probably be sensible to convert the code in the binary packer to write to a uint8 ArrayBuffer so I guess that is the next step. Once that is done it would be possible to just deal with sending data via packets.. (banks) in the same way other blitz languages do things. Avoiding strings on certain targets is a must!

Also another note, html5 sockets are like awesome, however unlike other sockets they require a "initialization" procedure. This needs to be taken into account on the serverside of things as well.


How do you mean? I have only read the documentation of the api and not really tried to get anything running yet.

A php server would be a bit mental and awesome :D as would a monkey php target ;)


Tibit(Posted 2011) [#13]
I'd go with a Socket-Class, and my suggestion is that it has a SocketSettings Property which the user can optionally set with data such as initialization data for html5.

Hm.. You have a good idea how we can write a simple test to verify bitPacking rutines across platforms?

Here is a html5 socket example. I haven't tested it but at first glance it looked promising.

* http://net.tutsplus.com/tutorials/javascript-ajax/start-using-html5-websockets-today/

AND

* http://www.codeproject.com/KB/HTML/Web-Socket-in-Essence.aspx

This is made for a php server, but just replace the php-server with an IP and you should be set!

Websockets are so awesome I so want them to be a reality among the larger part of the internet population.


Skn3(Posted 2011) [#14]
Ah I see, there is no peer 2 peer communication with websockets yet. Interesting that it is so limited. It wouldn't be that hard to write a router. I understand what you were referring to now with the php server!

It could also be a possibility to embed a flash movie to deal with network and let it communicate to javascript. Although that is a bit nasty.

What do you think the best course of action would be. Ignore html5 sockets for now, use flash, write/port a websocket server in blitzmax or use something like node.js?


Tibit(Posted 2011) [#15]
I think most times you want a server-client solution, unless the concern i latency. For P2P then going bluetooth or built-in wifi is probably a better bet for low latency.

btw talked to the founder of Atari last night, Nolan Bushnell. And He was sure that picoNets (small local wireless networks) will be huge in the future.

I buy that theory since if one game comes out that is popular - and you can play it locally (realtime) with anyone who has a smartphone, its a viral spread setup :)


Playniax(Posted 2011) [#16]
Nice how you just casually slipped that in, 'btw talked to the founder of Atari last night, Nolan Bushnell.'

He is your neighbour or what?

Just kidding, no harm intended :)


Tibit(Posted 2011) [#17]
He was in town, GameConference, he is pretty cool, gave an awesome keynote ;)

I actually asked him about it, and we discussed when it would happen. Do we have to wait until there is only one ubiquitous platform or could it work by doing like we are doing on here, cross-platform stuff.


Kieryn(Posted 2011) [#18]
Any updates to this? I'm new to Monkey and http requests were one of the first things I was looking to try out... how else can you take advantage of web services etc?


Xaron(Posted 2011) [#19]
I work on that atm... :)


Tibit(Posted 2011) [#20]
Xaron, please tell more, also do you got anything to share perhaps?

Atm I don't want to start wrapping native code, but I'm very happy to get going building simple networking and testing once there are some raw socket commands.


Skn3(Posted 2011) [#21]
No update from me for socket stuff I'm afraid!


Tibit(Posted 2011) [#22]
Xaron, you got an update?

I started building a TCP Server in C# to test against but also to start working on an API that will work across all platforms.

I was thinking that send/receive use byte arrays or strings. So you can send a byte-array or a string, and you can receive a byte-array or a string. Obviously the byte-array allows you to pack and unpack stuff however you want. The String stuff does a simple string conversion and also allows you to pack data into a string-format.

Here is some progress on the Interface Side for TCP. It could look like this (just pseudo code):

TCP.StartServer:TCPServer( port:int, networkInterfaceID:int = 0 )

'Create and Listen to a post is as simple as this:
Local myServer:TCPServer = TCP.StartServer( 5555 )

in OnUpdate:
If myServer.Pending
   Local newConnection:TCPConnection = myServer.AcceptConnection()
   If newConnection.Availible
      newConnection.Read() 'Read to buffer
      Local byteArray:byte[] = newConnection.ReadBuffer
      Local text:string = newConnection.ReadString
   End
End


In this case it is using blocking sockets, however it does not block anything since we check Pending and Available before calling Accept or Read, and when we do we only read the amount we have - so there is no waiting!

Unless someone intends to host a MMO server on their iPad I strongly suspect a synchronous approach like this will be simpler, easier to code, easier to debug, easier to use and in some cases faster, yet might not be supported on all platforms.

UDP will be slightly different due to not requiring Accept, however TCP will require more work than this on a higher level for normal game traffic due to it being a stream protocol - packets are never guaranteed to be complete - they can be cutoff anywhere. However I would not suggest adding a check for this in the lowest level of the library since if someone ever is going to use a server on another platform - then they will be dependent on our protocol.

Good to hear comments on where people here wants and what kind of support in sockets you seek. We'll make this a free-community module.


Xaron(Posted 2012) [#23]
No update yet, my time is limited but it becomes more and more urgent for me as well so I HAVE to implement more networking, lol.

So what I'm on is: Bluetooth, Socket communication (TCP) for Android, iPhone and Windows Phone 7.


Tibit(Posted 2012) [#24]
Xaron, if you send me what you have - even if just the interface - names of functions/methods & classes - I'll see if I can help in any way!

This project has so big potential, multiplayer on mobile is the future imo :)