In last month’s column, Dr. Edward G. Bradford, senior programmer at IBM, covered synchronization primitives and gave a reprise on pipes. This month he takes a first look at communication using sockets. Ed demonstrates some techniques for writing a sockets program and shows how his programming techniques perform in various operating system environments.
High-Performance Socket Programming on Linux & Windows
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
sorry I just thought that it is funny how poorly windows can communicate between apps over a network and they are going to try to deply a system like .NET.
Interesting that in the process sync paper, he noted how much faster Win32’s crit section code is. It should ALSO be noted, which he didn’t, use of this can significantly slow down other threads on an SMP system as this call prevents ALL context switches. That means, if you have six CPUs, each running a thread for the application, once each thread completes it’s task, no further processing will be allowed until the thread leaves it’s crit section. This is true even if the other threads were not in the same section of code. That means, for short durations, you create a window on which only a single CPU if functioning. While mutex’s have MUCH higher overhead, they are VERY much more SMP friendly! No you know why! In other words, if you use a mutex, the overhead is higher, however, all CPU’s can work unless they actually hit the same synchronization point. Imagine that!
hmmm, didn’t know that. I always tend to use crit. section rather than mutexes, because I’ve always been told that crits are so much faster. My stuff is running on a SMP box so this might be good to know! Mind you, we’re not even close to max out the server anyway so the diff. is nothing anyway for the moment. just out of interest, why does it pervent all context switches?
I do believe win does perform better with async socket (windows stylee). From what I’ve read (in msdn) is it with those MS tries to speed things up. don’t ask me why, but they *do* like to do it their way as always 😉
Yeah I guess your right. and of course when MS decides on a technology, they assume that they are only working with MS software (since to them, they are the only game in town)
can this be used in beos?
Hmm, according to the book ‘Win32 Network Programming’ (Ralph Davis) you need to use overlapped I/O in order to get the most out of windows sockets…
Now that’s always a laugh to program IMHO…(little bit of sarcasm)