The Old Joel on Software Forum: Part 3 (of 5) - Cross-platform sockets in C?

Cross-platform sockets in C?

Hi.

I've recently found myself in the position of having to write a lot of network code in C. It has to run on both Unix and Windows. I haven't done much network coding in C, and I'd rather not have to write separate code for sys/socket.h and Winsock.

Can anyone recommend any cross-platform sockets libraries for me to use? Ideally something simple that provides an abstract socket API to both socket.h and winsock, or something that provides the socket.h interface on both Unix and Windows?

Thanks.

Confused C Programmer
Friday, September 26, 2003

Does it have to be plain C? Can you use C++? The ACE[1] library is very well regarded in the C++ community for portable network programming.

[1] http://www.cs.wustl.edu/~schmidt/ACE.html

Chris Tavares
Friday, September 26, 2003

Unfortunately, it has to be in plain C.

Confused C Programmer
Friday, September 26, 2003

When last I tried this some years ago under NT4.0 there were, and probably still are, some real gotchas trying to make socket i/o code portable across Unix and Windows. The most notable of these was that Window has no concept of file descriptors, so you cannot treat sockets, pipes and files interchangeably. This means that fundamental calls like select() become unworkable. If you need to do anything more than just send and received stream data I would strongly recommend you get more than just a 'sockets' library.

Take a look at http://www.cygwin.org. This is pretty much a complete POSIX API bundled into a DLL. It even provides fork() and exec(), which amazes me considering how fundamentally different the Unix and Windows process models are!

David Roper
Friday, September 26, 2003

Sorry, that's http://www.cygwin.com. Hey, it's Friday and it's late....

David Roper
Friday, September 26, 2003

Well, the Berkeley sockets API has relatively portable semantics, but I'm not sure Win32 follows them accurately.

In any case, there are many abstraction layers for sockets:

APR - the Apache Portable Runtime - (ANSI C)
http://apr.apache.org/

ACE (like someone mentioned before me)

NSPR - the netscape portable run-time (used by Mozilla) -
I'm not sure if it's C or C++.

Boost - a C++ framework that provides portable abstraction for sockets (among else). It has good Standard C++ (STL and all) operation.

You can find more potentially useful links here:

http://vipe.technion.ac.il/~shlomif/abstraction/

and on Freshmeat.

Shlomi Fish
Friday, September 26, 2003

just follow the Berkeley sockets, and your set. Above those, windows only needs an init call to start the socket stuff.

If you are doing select() calls, make sure you only do them on the sockets and nothings else.

Portable socket code is pretty straight forward.

Happy to be working
Friday, September 26, 2003

The other thing to worry about is that select is the wrong way to do sockets under Windows. The performance just blows. You want to use the Async I/O calls instead.

If you're writing a client app, you'll probably be ok. If you need to be on the server, I'd say bite the bullet and do the separate versions.

Chris Tavares
Friday, September 26, 2003

If you want to get the maximum benefit and performance from each platform's implementation and you don't want to use an available cross platform library, you really should implement certain functions differently. As an example, it would be criminal not to use WSAAsyncSelect() on Windows for event notifications.

I don't think you will get the performance you would like under load with a generic implementation. Best to use platform specific functions where available.

Tim
Friday, September 26, 2003

>>
The most notable of these was that Window has no concept of file descriptors, so you cannot treat sockets, pipes and files interchangeably.
<<

Maybe I'm misunderstanding what you mean but once you have a handle to a socket, pipe, or file, they can be used interchangeably with API calls such as ReadFile and WriteFile.

SomeBody
Friday, September 26, 2003

I recalled reading somewhere that socket handles are not file handles in windows. I went back and found it in MSDN, from which I ripped the following, which is hopefully not a copyright violation they'll come after me for ;)

Socket Handles for Windows Sockets 2

A socket handle can optionally be a file handle in Windows Sockets 2. It is possible to use socket handles with ReadFile, WriteFile, ReadFileEx, WriteFileEx, DuplicateHandle, and other Windows functions. Not all transport service providers support this option. For an application to run over the widest possible number of service providers, it should not assume that socket handles are file handles.

Tim
Friday, September 26, 2003

Netscape's NSPR is plain C and very cross-platform. I've used the NSPR for some simple programs and I was impressed. Mozilla uses NSPR, so you know it is very well tested. :-)

One problem might be that it has an open-source license that requires you to release changes you make to the NSPR source files, but not your own source files. Rebuilding NSPR yourself is difficult, but you don't have to because Netscape has pre-built libraries (static and dynamic/DLL) you can download and ship

runtime
Friday, September 26, 2003

"A socket handle can optionally be a file handle in Windows Sockets 2."

It may say optional, but in practice I've never seen a socket handle on any version of Windows that wasn't actually a file handle.

This out is there for people implementing other network stacks like IPX or Decnet or Vines or whatever. If you're using TCP/IP, a socket handle *is* a windows HANDLE, and you can use all the appropriate API calls.

HOWEVER - the select( ) call, as far as I know, only works on sockets, not files, like it does on Unix. That may be what the original poster was referring to.

This is yet another reason why asynch IO rather than select is the way to go on Win32.

Chris Tavares
Friday, September 26, 2003

The Imatix standard function library:

http://www.imatix.com/html/sfl/

has exactly what you need.

While you're there, take a look at their Xitami web server. Small, fast, and exactly the way software should be.

HeWhoMustBeConfused
Friday, September 26, 2003

Thanks for all of the replies.

The SFL, as well as some tools I found at freshmeat, seem to be exactly what I was looking for.

This group has been most helpful. I asked the exact same question on comp.lang.c, and was told, in no uncertain terms, that any questions about sockets—apparently even questions about C socket libraries—were off-topic.

Confused C Programmer
Saturday, September 27, 2003

Sockets _are_ off-topic for comp.lang.c.

comp.lang.c exists to talk about the C language, not about specific implementation details. If sockets were part of the C language specification, then it would be on tpopic.

The reason for this is simple - there are plenty of issues to talk about in C without talking about specific implementations/technologies. The newsgroup would be overrun with people asking Windows/Unix/VMS/BeOS/... specific questions ('but I'm doing it in C...') if they starting allowing this type of question.

It's all in the faq for the newsgroup. You did read it before posting?

RocketJeff
Saturday, September 27, 2003