socket
A portable and extensible sockets library.
https://github.com/lpeterse/haskell-socket
| Version on this page: | 0.5.3.0@rev:1 |
| LTS Haskell 24.18: | 0.8.3.0@rev:2 |
| Stackage Nightly 2025-11-01: | 0.8.3.0@rev:2 |
| Latest on Hackage: | 0.8.3.0@rev:2 |
socket-0.5.3.0@sha256:2dd7a1d3117389e1efa5fa6149925c6bd912116a68c2b2ee1370911b106440fc,5987Module documentation for 0.5.3.0
socket
Motivation
This library aims to expose a minimal and platform-independant interface for POSIX compliant networking code.
Implementation Philosophy
-
Every operation and every flag exposed should be supported with same semantics on every platform. If this cannot be guaranteed it should be supplied by another (extension) package. Examples for things that have been ripped out of this library are:
- Support for Unix sockets which don’t have an equivalent on Windows.
- Support for SCTP.
- Support for vectored IO (at least unless it can be guaranteed to be supported on all platforms).
-
Absolutely no conditional exports.
-
No
#ifdefmadness in the Haskell sources. The Haskell binding code uses the FFI to reference the platform’s native networking functions. If they are not Posix compliant (i.e. on Windows) an level of indirection is introduced to create an Posix compliant equivalent in C using whatever the plaform specific building blocks are.
Platform Support
Linux
Working.
BSD
Unknown. Should work. Please report if not.
MacOS
Working.
Windows
Fully supported on Windows7 (maybe Vista) or higher :-)
GHCs runtime system on Windows does not offer an event notification mechanism for sockets. The original network library suffers from this, too. For example, connection attempts are uninterruptible etc. The approach taken to circumvent this in this library is to poll the non-blocking sockets with increasing delay. This guarantees interruptability and fairness between different threads. It allows for decent throughput while also keeping CPU consumption on a moderate level if a socket has not seen events for a longer period of time (maximum of 1 second delay after 20 polling iterations). The only drawback is potentially reduced response time of your application. The good part: Heavy load (e.g. connection requests or incoming traffic) will reduce this problem. Eventually your accepting thread won’t wait at all if there are several connection requests queued.
This workaround may be removed if someone is willing to sacrifice to improve the IO manager on Windows.
Dependencies
- base
- bytestring
Tests
Run the default test suites:
cabal test