I think a sockets addon for allegro would be extremely useful. Even just some basic functions that abstract sockets across platforms would be useful. Pretty much all of my games require sockets, and if allegro included sockets it would be the only library I need. I think a lot of modern games use network connectivity for various things, and sockets should be a part of game libraries, and by being a simple addon, people could still use more advanced socket libraries if they want (like RakNet).

Just thought I would throw the idea out there. What are your thoughts on this?

You don't need another library to use sockets. Under Linux/OSX/iOS they are part of libc. Under Windows you just have to link against wsock2 which is a system component. I don't know about Android but I'm quite sure it also has sockets.

So, if you use sockets, they should be available everywhere.

I do agree though, a wrapper to hide the platform differences would be nice. Maybe just copy the sockets API, with reduced functionality and always blocking. Something like:

Each function would either return >= 0 if successful or a negative error code. Would probably only need one error code which tells to close the socket and recreate it.

I think it would take about half an hour to write, including the platform differences (e.g. under Windows, have to call WSAInit...). Still, I'd feel like a serious case of re-inventing the wheel

To me, an Allegro addon would mean something like integration with the file API:

al_fwrite(socket, "Hello", 6);

and the events API:

if (event.type == ALLEGRO_EVENT_PACKET_RECEIVED) 
{
}

(Not that you'd use those two methods together.)

Anybody wanting to write some low-latency networking code would use something else.

I've said this for years and been told to write one of my own to submit as a possible add-on for Allegro. Sadly my socket programming is minimal so the start I had on an add-on is rather pathetic. I need to scrap my old code (minimal as it is) and start playing with it again.

I agree. But then I don't really see the point anymore. Instead of using a TCP stream to access a website, why not use libcurl which handles a lot of stuff like ssl and cookies and so on. And instead of sending UDP packets, why not use Enet which already handles all the platform differences and has a way of sending reliable messages.

I guess the point would be to have all the "basics" in a single Library, particularly in a game game-versed one like Allegro to be more complete.

...so the "basic" user may have only one single actual dependency in his projects.

I suppose thou that having only "basics" is not really attractive altogether in a low-level lib like Allegro.

And, but that may be just me since I am no hard-core programmer at all, I do not think that linking aganist a set of dependencies instead of just one (which in any case shells a sub-tree of them) matters all that much.

Of course this requires you to master more than one API.

This would mostly mean creating the Windows .dll in a way which includes Enet and/or libcurl. No code changes to Allegro required. Just Mical would have to adjust his Windows build scripts.

My main point is that a network addon that does not integrate with Allegro is completely useless, due to other libraries already existing.

e.g., Using libcurl as the backend, you could do this:

al_fopen("https://www.allegro.cc/forums/recent", "r");

But if you're just going to write a low level API or a higher thing that mimics something like enet without proper Allegro integration, then it's a complete waste of time in my opinion.

http://libevent.org/

Libevent is a portable way to do networking on all sorts of platforms. It's BSD licenced, and it has very high performance. Some wrapper functions could be written to inegrate this better with allegro, but I don't see much need for that. There's a lot of portable libraries for C out there that need not be integrated in allegro to use them.

It'd be stupid simple to support BSD Sockets via the fshooks api. Espeically if all you care about is blocking sockets. Some additions would have to be made to support non blocking sockets (ie: add al_select, ALLEGRO_SOCKET_*_EVENT, etc). To support host/server type sockets more apis would be needed like al_listen and al_accept.

But again, its not a difficult job. If anyone wants to do it, I'd be up for mentoring should they need it.

I was thinking of developing an addon even just for personal use since I do have good experience working with sockets, but I'm not really sure how the internals of allegro are structured and how to actually go about making an addon.

I normally use RakNet for my larger projects, and I have no trouble linking more than one library, but I do think sockets built into allegro would be handy for some small projects I like to throw together sometimes. RakNet seems also pretty bloated for use on a mobile device, which is primarily what I'll be aiming at in the next little while.

Anyway, Maybe I'll look at some of the other addons and play around with it and write one eventually.

If you really wanted to do this, you could start with the memfile addon as a base for the sockets addon. It implements a bare fshook driver that you can extend to support sockets.

Some extra APIs will need to be added, they may need to be hung off the core fshook driver vtables. I think its fairly straight forward, especially if you're familiar with sockets already.