QuickSock: A simple UDP socket module (GLFW / C++)
Monkey Forums/User Modules/QuickSock: A simple UDP socket module (GLFW / C++)
| ||
Major Project Updates: * (V1.1): Besides some bug fixes, slightly better performance, and the ability to compile for other desktop platforms; this version is pretty much the same as V1.0 for Monkey users. The only noticeable difference while programming in Monkey is that "IsServer" is now a method, instead of a field. You can find a full list of updates for the C++ version here: Source Forge --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Here's where you can find the Monkey module(Downloads page): Source Forge - Just extract the zip to your modules folder, and that's it! QuickSock is also available for free to C++ developers(Available for Windows, Mac, Linux, etc): Source Forge QuickSock currently supports: STDCPP(Only tested on Windows) & GLFW(Windows, Mac, and Linux). And from what I've tested, Visual C++ 2010 and MinGW/GCC should work without any problems. Module Description: QuickSock is a simple project I've been working on for a little while now. It's completely open source, so edit it and redistribute it as you like. Credit for the original work would be appreciated, but it's not a requirement. My main goal with QuickSock is to allow you to get sockets running, without having to do all the work setting them up. Right now, QuickSock exists as a simplistic layer between WinSock/BSD-Sockets, and the programmer. Extra Information: I wrote QuickSock in C++, and since I've never really tried to work realistically with it, I encourage you to tell me your thoughts on the C++ side of things. I'd like to make this as clean and compact as possible. TODO List: * Reliable packets(C++ or Monkey) * Stream support(Monkey and/or C++) * Asynchronous Sockets(Monkey or C++) * TCP Sockets(C++) / Better error checking(C++) X Support for other platforms(C++) If you find any bugs while using QuickSock, please report them. |
| ||
{UPDATE, V1.1(April, 2013)}: QuickSock now supports BSD-Sockets, so it should be able to run on Mac OS-X and Linux. I haven't tested it on Mac OS-X, so I'd really appreciate it if you could tell me if it at least compiles on OS-X. I have tested QuickSock on Linux both normally, and with Monkey, and everything seems to work. |
| ||
{SMALL-UPDATE, V1.1.1(April, 2013)}: I've tested QuickSock on Mac OS-X via XCode, and with a few tweaks I got everything running. Anyone who wants to run QuickSock on Mac OS-X via Monkey should download the V1.1.2 Monkey module patch. And for C++ users there's an updated header in the 'Code' section on Source Forge (Under the "V1.1" folder). QuickSock should now have no problems running on all of Monkey's C++ desktop targets (Excluding Windows 8 / Window Phone 8). |
| ||
Nice Work really! I was looking like a week for the Right Networking Module, and here it is :D. My Problem: I don't understand "native-C++" so i just only could work with your Example and it was really hard to figure out, how to use it for my own project. But in the End, i made a little "Server-App" using Chellenger GUI. It's the first time i coded with networking stuff, and it worked within the first 5 tries, so i guess ur module is easy enough for newbies to understand if you have time to read your example. Question: Is it possible to use another network module for Android for example so i can connect a Linux/Win8 Server with Android Smartphones? Or maybe HTML. (Sorry if the question is stupid, I'm really new to this) My Aim is to setup a Server at home running on Windows/Linux (GLFW) with your networking module and connect it with a Client_Chat-Software running on HTML5/Android ... Here is my little Server-App. It works fine with your example. I've tested it with your example on the Same PC and even on the Laptop connected via WiFi over a Router. If i'll have time Ill write the Client Program as well Keep on! And very much thank for your OpenSource Module Sorry for bad english. Duke87 |
| ||
A lot of folks here usually use something else for the server side. Blitzmax is one. I also would recommend MS products. You can get the express versions for free. It is fairly easy to knock up a nice server in vb.net or C#. |
| ||
Erlang is a really good choice for servers—especially anything related to chat. http://veldstra.org/whyerlang/ Many modern techs which have high fault tolerance and concurrency built in are also good choices. I would stay far away from anything which doesn't have those two things as part of their foundation. |
| ||
Just curious why you guys aren't using brl.socket? |
| ||
Mark Sibly: Just curious why you guys aren't using brl.socket? QuickSock was initially released before you added socket functionality, thus the reason for the Monkey wrapper. I use it today because my code was already written with it, and I like to have complete control. And, it's available to any C++ developer, so you'll get the same experience with C++ (With or without Monkey). I also made it a bit more streamlined than BRL.Socket. It's also 100% open source, and C++ developers can improve Monkey developers' experiences. The real question is "Why should we use BRL.Socket?". Sure, if this wasn't my library, and I was just starting to write UDP socket code, I would go with BRL.Socket, but I don't see anything wrong with using a 3rd party library/module. People used 3rd party modules/libraries all the time with BlitzMax and BlitzBasic. I'm currently working on a reliable (UDP based) high-level networking module, and it relies on QuickSock and ANet. However, if there's enough interest in it, I may add support for BRL.Socket. Perhaps the biggest downside with using QuickSock is the fact that it's an unofficial project, but since this is my own project, and I rely on it heavily, I'll make sure to keep it stable. That being said, I forgot to add a 'Free' command in the latest public build, so there's probably a bit of a memory leak going on (Nothing major though). This is fixed in the version I'm working on, but I'll need to finish IPV6 support to release this (Not sure if I can get IPV6 working with Monkey or not). This version also supports Visual Studio 2010/2012 with the XP toolset without having to use Monkey. VS2012 users using the XP platform toolset will have to enable QSOCK_WINDOWS_LEGACY (Define it and set it to 1). At the end of the day, I did this because there weren't options for UDP in Monkey; that was one of the main reasons I made the leap into programming with C and C++. I'll probably make QuickSock into a wrapper for BRL.Socket at some point, and just keep it as a C++ library. |
| ||
I'm currently working on a reliable (UDP based) high-level networking module, and it relies on QuickSock and ANet. However, if there's enough interest in it, I may add support for BRL.Socket. I'm happy to see that ANet could be to any use of anything ;) |
| ||
There is also WebSockets... don't underestimate websockets! |
| ||
Rushino: There is also WebSockets... don't underestimate websockets! Well, WebSockets would be great if there was support for UDP. I have heard of things like WebRTC though, and that could possibly work. I'm kind of reluctant to use TCP because of my bad experiences with it. Plus, part of the charm of my new networking module is the fact that it's reasonably fast and optionally reliable. I may look into BRL.Socket and sockets with Flash though. For those who are wondering, here's a rundown of most of the features so far: * Support for both GLFW, and Android. (Like I said before, I may support BRL.Socket if there's enough interest) * Basic encryption (Currently only RC4, but it's pretty modular) * Automated connection pinging and disconnection handling. (If it wasn't obvious already, this is for servers) * Faked peer-to-peer messaging. (Clients can send messages to each other manually, or through a reply) * Optional reliable messaging. * Internal and external packets. (Used for basic things like pinging, and initializing; nothing useful to the average user) * A somewhat interesting "virtual address" system (Mainly for clients). * The possibility to write packets yourself (As long as you conform to my basic internal header standards) * Basic messaging security. (You have to identify as a client to work with the server. All packets from unidentified sources are considered join requests.) * Optional encrypted password identification. * Both integer and string IP support for most features. (Converts to strings anyway) |
| ||
> The real question is "Why should we use BRL.Socket?" I was really just curious if BRL.Socket was 'missing' anything. But the major 'plus' to using BRL.Socket is that it works on android, ios, win8 too... |
| ||
Wait, it works on iOS? I had no idea it supported it, now I'll definitely look into adding it to my module. I'll probably just add an option to rely on BRL.Socket for Android and GLFW. I was thinking of programming iOS support myself, but if BRL.Socket supports it, I don't really need to. EDIT: Looking over some of the commands, it seems you're using BRL.DataBuffer, I'm already using it, so this should be easy enough. |