HORIZON HASKELLDocslts/ghc-9.10.x248f8f02026-10-05Search names, modules, packages, or :: a typeCtrl K

GHC 9.10.3 · lts/ghc-9.10.x · 248f8f0 · 2026-10-05

Modulenetwork-3.2.8.0Haskell2010

Network.Socket.Address

This module provides extensible APIs for socket addresses.

  • 1 class
  • 12 values
  • Packagenetwork-3.2.8.0
  • Exports13
  • LanguageHaskell2010
  • LicenceBSD-3-Clause
  • SourceAddress.hs

Socket Address

3 declarations

Socket operations

3 declarations
valuebind :: SocketAddress sa => Socket -> sa -> IO ()
#

Bind the socket to an address. The socket must not already be bound. The Family passed to bind must be the same as that passed to socket. If the special port number defaultPort is passed then the system assigns the next available use port.

valueaccept :: SocketAddress sa => Socket -> IO (Socket, sa)
#

Accept a connection. The socket must be bound to an address and listening for connections. The return value is a pair (conn, address) where conn is a new socket object usable to send and receive data on the connection, and address is the address bound to the socket on the other end of the connection. On Unix, FD_CLOEXEC is set to the new Socket.

Sending and receiving ByteString

3 declarations
valuesendTo
  1. :: SocketAddress sa
  2. => Socket

    Socket

  3. -> ByteString

    Data to send

  4. -> sa

    Recipient address

  5. -> IO Int

    Number of bytes sent

#

Send data to the socket. The recipient can be specified explicitly, so the socket need not be in a connected state. Returns the number of bytes sent. Applications are responsible for ensuring that all data has been sent.

valuesendAllTo
  1. :: SocketAddress sa
  2. => Socket

    Socket

  3. -> ByteString

    Data to send

  4. -> sa

    Recipient address

  5. -> IO ()
#

Send data to the socket. The recipient can be specified explicitly, so the socket need not be in a connected state. Unlike sendTo, this function continues to send data until either all data has been sent or an error occurs. On error, an exception is raised, and there is no way to determine how much data, if any, was successfully sent.

valuerecvFrom
  1. :: SocketAddress sa
  2. => Socket

    Socket

  3. -> Int

    Maximum number of bytes to receive

  4. -> IO (ByteString, sa)

    Data received and sender address

#

Receive data from the socket. The socket need not be in a connected state. Returns (bytes, address) where bytes is a ByteString representing the data received and address is a SockAddr representing the address of the sending socket.

If the first return value is zero, it means EOF.

Sending and receiving data from a buffer

2 declarations
valuesendBufTo :: SocketAddress sa => Socket -> Ptr a -> Int -> sa -> IO Int
#

Send data to the socket. The recipient can be specified explicitly, so the socket need not be in a connected state. Returns the number of bytes sent. Applications are responsible for ensuring that all data has been sent.

valuerecvBufFrom :: SocketAddress sa => Socket -> Ptr a -> Int -> IO (Int, sa)
#

Receive data from the socket, writing it into buffer instead of creating a new string. The socket need not be in a connected state. Returns (nbytes, address) where nbytes is the number of bytes received and address is a SockAddr representing the address of the sending socket.

If the first return value is zero, it means EOF.

For Stream sockets, the second return value would be invalid.

NOTE: blocking on Windows unless you compile with -threaded (see GHC ticket #1129)

Advanced IO

2 declarations
valuerecvBufMsg
  1. :: SocketAddress sa
  2. => Socket

    Socket

  3. -> [(Ptr Word8, Int)]

    A list of (buffer, buffer-length) pairs. If the total length is not large enough, MSG_TRUNC is returned

  4. -> Int

    The buffer size for control messages. If the length is not large enough, MSG_CTRUNC is returned

  5. -> MsgFlag

    Message flags

  6. -> IO (sa, Int, [Cmsg], MsgFlag)

    Source address, total bytes received, control messages and message flags

#

Receive data from the socket using recvmsg(2). The supplied buffers are filled in order, with subsequent buffers used only after all the preceding buffers are full. If the message is short enough some of the supplied buffers may remain unused.