Thread: Library recommendation?

Hi.

I'm looking for a fairly basic, cross-platform, easy to use sockets library. When I say cross-platform, I really only care about Windows and Linux/BSD; I don't care about supporting all sorts of really obscure platforms at this point...

It's for a multiplayer game, the networking of which should be relatively simple (as opposed to the actual game logic, which thankfully I've got figured out just fine...). I've heard that OpenSSL has a subset of more basic functions for those who don't want its full functionality, but I'm wondering if it's worth forcing users to have it (especially Windows users who are unlikely to have it already) if I'm only using a tiny bit of it.

Are there one or more popular libraries that are generally considered the 'standard' one[s] to use for something like this? I'm writing the game in C++, so obviously a C library would be fine, but if there's one written in C++ and/or handles threading (I'll be wanting multiple clients connected at a time, so I presume I'll need to do something about that) and does some other funky stuff to make using it cleaner/easier then that would be preferred.

Any comments or suggestions appreciated!

Cheers!

Try checking out www.wxwindows.org
It's a cross-platform GUI library, but it does include a base (non GUI) called wxBase where it utilizes cross-platform sockets, files, etc. I don't know if it would work on BSD, but I don't see why there would be a problem.

There is also http://www.gnu.org/software/commoncpp/
Don't know anything about it, but it just proves I'm a better searcher than you.

Quantum - That's true, but not with asynchronous sockets, right? I've never done linux programming at all, but I would think if using asynchronous sockets, for cross-platform-ism you would need more than a few #ifdef's. But if using regular blocking/nonblocking sockets then a few #ifdef's would work.

Am I right in thinking that?

Originally Posted by Quantum1024

Socket programming on windows isn't that different from Linux. A few #ifdef's here and there would do it.

I think I'll take that option, then.

neandrake: what's the distinction between regular non-blocking sockets and asynchronous sockets?

Thanks

PsychoBrat - Non-blocking have to be handled with threads in order to work with multiple connections. Well you don't need threads, but you have to manually check on sockets. Asynchronous sockets use window's messaging system in order to deal with them. I've used asynchronous sockets way more than any other so I'm more familiar with it.

Originally Posted by Johnnie's Winsock Tutorial

A non-blocking socket returns immediately whenever it is told to do something, either with a successful result, an error, or nothing (indicating that there will be something to receive later). The disadvantage of using this type is that you'll have to manually query the socket to see if a result has come in on every function you call. You can pass a set of sockets to the select() function to see which ones are ready for reading, writing, or have returned errors.

Functions using asynchronous sockets also return immediately, but you can specify a message to send to your window procedure when a specified event has occurred.

Thanks

I think I'll stick to regular non-blocking sockets w/ threads.

(and thanks to everyone else for their input )

Originally Posted by neandrake

Quantum - That's true, but not with asynchronous sockets, right? I've never done linux programming at all, but I would think if using asynchronous sockets, for cross-platform-ism you would need more than a few #ifdef's. But if using regular blocking/nonblocking sockets then a few #ifdef's would work.

Am I right in thinking that?

I believe you're correct about asynchronous sockets at least when using windows messaging. I was thinking of regular blocking/nonblocking sockets when I wrote my post and hadn't even considered asynchronous sockets use of windows messaging.

Select() exists on both platforms so on linux I think you'd need to write your own WSAAyncSelect() function to check sockets and output messages. But then you don't have to stick to the windows paradigm to create an asynchronous socket application.