So whats the future of UDP and Monkey?
Monkey Archive Forums/Monkey Discussion/So whats the future of UDP and Monkey?
| ||
| Hi All, I am starting to port my Phoenix USC project to Monkey and UDP is a must for me. It looks as if at present there is just no real reliable UDP support for IOS and Andriod. Anet I've seen has some issues. So why no support for UDP in general? Is it just to daunting a task? With BlitzMax I can cover Mac, Linux and Winblowz but I need to use Monkey to support IOS and Android for my project. Just wondering what's going on with UDP support. - Rich - |
| ||
| No takers? Really, I'm open to suggestions. My view here is that many of us needs this feature. It is one of the issues that makes it impossible to port from Blitzmax to Monkey for serious game applications. Stepping outside Monkey's uniform target support might makes sense if the goal is to encourage large scale development projects. - Rich - |
| ||
| a little twitter bird said BRL may be working on a networking module, so we'll have to wait to see if that includes UDP. Quicksock offers windows & perhaps others: http://monkeycoder.co.nz/Community/posts.php?topic=4866 Anet for android: http://monkeycoder.co.nz/Community/posts.php?topic=3275 |
| ||
| I'm currently in the process to wrap the new Google gaming API which is cross platform. |
| ||
| Hi, Google gaming API which is cross platform That's cool but as I read about that API it has limitations that inhibit MMO style games. Take this quote from Google (https://developers.google.com/games/services/common/concepts/realtimeMultiplayer). Once the required number of participants for a game have been connected, your app can start a gameplay session. After all participants have joined a game and the room is "full", players can leave your game, but no other players can join; not even to fill a spot that another player has vacated. What I need is UDP access, something like we have with BnetEx on BlitzMAX. Developing my own MMO and server requires a lower level access to UDP then say the GG API offers even when it's just the client. a little twitter bird said BRL may be working on a networking module, so we'll have to wait to see if that includes UDP. Adam. :D Welcome news indeed. UDP would make it just freaking awesome. I can only hope. - Rich - |
| ||
| I've just pushed a new experimental brl.socket module to the github develop branch that provides a generic Socket class that supports udp. This works on android, ios, win8, glfw. However, winstore 8 apps currently only support "stream" sockets. Winphone 8 apps support everything. To give it a try, checkout the github develop branch - you can checkout to a new dir and just copy the "docs", "modules/brl" and "bananas/mak" dirs into your release. Don't forget to rebuild help! Simple examples can be found in bananas/mak/echoserver_tcp and echoserver_udp. I've also modified HttpRequest to use brl.socket instead of brl.tcpstream. After initially experimenting with a separate UdpSocket class, I decided to move to a single Socket class because: a) It's what many people are used to and b) there is a *lot* of commonality between different socket types that IMO it makes sense to exploit - even on targets with APIs that have different classes for different socket types like java/winrt. It also means the c++ version is nice and easy to write... The new Socket class is quite different from TcpStream and TcpServer. For starters, it provides both synchronous (eg: Send) and asynchronous (eg: SendAsync) methods in the same interface (although it currently doesn't check to make sure you're not using both at the same time). Also, it doesn't attempt to 'stream-ify' sockets in any way so you're limited to having to send/receive things from/to databuffers. I'll probably do a SocketStream wrapper eventually, but this is less useful than you might think. Stream ops can only really be used synchronously (mainly because I do NOT want to get into ReadIntAsync etc territory), but you're supposed to use sockets asynchronously or you run the risk of getting apps rejected by google/apple when you try to publish. I'm thinking of retiring TcpStream, AsyncTcpStream, AsyncTcpConnector (ugh) and TcpServer in favor of Socket. I'll leave them in the release and continue to maintain them, but please use Socket instead from now on. A few notes: * This is a WIP so it's subject to change. * Why the BindAsync? IMO, bind should be a fast/cheap operation, but apparently winrt disagrees as its Bind is asynchronous. However, all my examples just use plain synchronous Bind and I doubt you'll run into any problems doing the same. * Bind/BindAsync take a host/port pair. I'm really only used to binding to a port, but over the last few days I've found a few examples which doing something fancy here so I've left host in as an option. Set it to "" to just bind to a port only. * Don't use Socket and TcpStream in the same app. |
| ||
| Exciting stuff! The winrt networking stuff is PITA! Would it be possible to use those newish preprocessor flags/caps to restrict targets? (instead of the #Error Invalid Target) Someone might be tempted to do a websocket implementation that hooks in to this module... |
| ||
| Hi, To quote myself "just freaking awesome". I'm off to get my copy. :D I can't tell you enough how thankful I am for this. - Rich - |
| ||
| This makes me Happy! Looking forward to experiment with this :) |
   |