2020-05-18 15:59:07 +03:00
|
|
|
||| Low-Level C Sockets bindings for Idris. Used by higher-level, cleverer things.
|
|
|
|
|||
|
|
|
|
||| Original (C) SimonJF, MIT Licensed, 2014
|
|
|
|
||| Modified (C) The Idris Community, 2015, 2016, 2019
|
|
|
|
module Network.Socket
|
|
|
|
|
|
|
|
import public Network.Socket.Data
|
|
|
|
import Network.Socket.Raw
|
|
|
|
import Data.List
|
2020-05-20 22:09:56 +03:00
|
|
|
import Network.FFI
|
2020-05-18 15:59:07 +03:00
|
|
|
|
|
|
|
-- ----------------------------------------------------- [ Network Socket API. ]
|
|
|
|
|
|
|
|
||| Creates a UNIX socket with the given family, socket type and protocol
|
|
|
|
||| number. Returns either a socket or an error.
|
|
|
|
export
|
Back to HasIO, remove MonadIO
Following a fairly detailed discussion on slack, the feeling is
generally that it's better to have a single interface. While precision
is nice, it doesn't appear to buy us anything here. If that turns out to
be wrong, or limiting somehow, we can revisit it later. Also:
- it's easier for backend authors if the type of IO operations is
slightly less restrictive. For example, if it's in HasIO, that limits
alternative implementations, which might be awkward for some
alternative back ends.
- it's one less extra detail to learn. This is minor, but there needs to
be a clear advantage if there's more detail to learn.
- It is difficult to think of an underlying type that can't have a Monad
instance (I have personally never encountered one - if they turns out
to exist, again, we can revisit!)
2020-06-21 21:21:22 +03:00
|
|
|
socket : HasIO io
|
2020-06-21 17:25:40 +03:00
|
|
|
=> (fam : SocketFamily)
|
2020-05-18 15:59:07 +03:00
|
|
|
-> (ty : SocketType)
|
|
|
|
-> (pnum : ProtocolNumber)
|
2020-06-21 17:25:40 +03:00
|
|
|
-> io (Either SocketError Socket)
|
2020-05-18 15:59:07 +03:00
|
|
|
socket sf st pn = do
|
2020-07-21 14:30:33 +03:00
|
|
|
socket_res <- primIO $ prim__idrnet_socket (toCode sf) (toCode st) pn
|
2020-05-18 15:59:07 +03:00
|
|
|
|
|
|
|
if socket_res == -1
|
|
|
|
then map Left getErrno
|
|
|
|
else pure $ Right (MkSocket socket_res sf st pn)
|
|
|
|
|
|
|
|
||| Close a socket
|
|
|
|
export
|
Back to HasIO, remove MonadIO
Following a fairly detailed discussion on slack, the feeling is
generally that it's better to have a single interface. While precision
is nice, it doesn't appear to buy us anything here. If that turns out to
be wrong, or limiting somehow, we can revisit it later. Also:
- it's easier for backend authors if the type of IO operations is
slightly less restrictive. For example, if it's in HasIO, that limits
alternative implementations, which might be awkward for some
alternative back ends.
- it's one less extra detail to learn. This is minor, but there needs to
be a clear advantage if there's more detail to learn.
- It is difficult to think of an underlying type that can't have a Monad
instance (I have personally never encountered one - if they turns out
to exist, again, we can revisit!)
2020-06-21 21:21:22 +03:00
|
|
|
close : HasIO io => Socket -> io ()
|
2020-07-21 14:30:33 +03:00
|
|
|
close sock = do _ <- primIO $ prim__socket_close $ descriptor sock
|
2020-05-20 22:09:56 +03:00
|
|
|
pure ()
|
2020-05-18 15:59:07 +03:00
|
|
|
|
|
|
|
||| Binds a socket to the given socket address and port.
|
|
|
|
||| Returns 0 on success, an error code otherwise.
|
|
|
|
export
|
Back to HasIO, remove MonadIO
Following a fairly detailed discussion on slack, the feeling is
generally that it's better to have a single interface. While precision
is nice, it doesn't appear to buy us anything here. If that turns out to
be wrong, or limiting somehow, we can revisit it later. Also:
- it's easier for backend authors if the type of IO operations is
slightly less restrictive. For example, if it's in HasIO, that limits
alternative implementations, which might be awkward for some
alternative back ends.
- it's one less extra detail to learn. This is minor, but there needs to
be a clear advantage if there's more detail to learn.
- It is difficult to think of an underlying type that can't have a Monad
instance (I have personally never encountered one - if they turns out
to exist, again, we can revisit!)
2020-06-21 21:21:22 +03:00
|
|
|
bind : HasIO io
|
2020-06-21 17:25:40 +03:00
|
|
|
=> (sock : Socket)
|
2020-05-18 15:59:07 +03:00
|
|
|
-> (addr : Maybe SocketAddress)
|
|
|
|
-> (port : Port)
|
2020-06-21 17:25:40 +03:00
|
|
|
-> io Int
|
2020-05-18 15:59:07 +03:00
|
|
|
bind sock addr port = do
|
2020-07-21 14:30:33 +03:00
|
|
|
bind_res <- primIO $ prim__idrnet_bind
|
2020-05-20 22:09:56 +03:00
|
|
|
(descriptor sock)
|
|
|
|
(toCode $ family sock)
|
|
|
|
(toCode $ socketType sock)
|
|
|
|
(saString addr)
|
|
|
|
port
|
2020-07-21 14:30:33 +03:00
|
|
|
|
2020-05-18 15:59:07 +03:00
|
|
|
if bind_res == (-1)
|
|
|
|
then getErrno
|
|
|
|
else pure 0
|
|
|
|
where
|
|
|
|
saString : Maybe SocketAddress -> String
|
|
|
|
saString (Just sa) = show sa
|
|
|
|
saString Nothing = ""
|
|
|
|
|
|
|
|
||| Connects to a given address and port.
|
|
|
|
||| Returns 0 on success, and an error number on error.
|
|
|
|
export
|
Back to HasIO, remove MonadIO
Following a fairly detailed discussion on slack, the feeling is
generally that it's better to have a single interface. While precision
is nice, it doesn't appear to buy us anything here. If that turns out to
be wrong, or limiting somehow, we can revisit it later. Also:
- it's easier for backend authors if the type of IO operations is
slightly less restrictive. For example, if it's in HasIO, that limits
alternative implementations, which might be awkward for some
alternative back ends.
- it's one less extra detail to learn. This is minor, but there needs to
be a clear advantage if there's more detail to learn.
- It is difficult to think of an underlying type that can't have a Monad
instance (I have personally never encountered one - if they turns out
to exist, again, we can revisit!)
2020-06-21 21:21:22 +03:00
|
|
|
connect : HasIO io
|
2020-06-21 17:25:40 +03:00
|
|
|
=> (sock : Socket)
|
2020-05-18 15:59:07 +03:00
|
|
|
-> (addr : SocketAddress)
|
|
|
|
-> (port : Port)
|
2020-06-21 17:25:40 +03:00
|
|
|
-> io ResultCode
|
2020-05-18 15:59:07 +03:00
|
|
|
connect sock addr port = do
|
2020-07-21 14:30:33 +03:00
|
|
|
conn_res <- primIO $ prim__idrnet_connect
|
2020-05-20 22:09:56 +03:00
|
|
|
(descriptor sock) (toCode $ family sock) (toCode $ socketType sock) (show addr) port
|
2020-05-18 15:59:07 +03:00
|
|
|
|
|
|
|
if conn_res == (-1)
|
|
|
|
then getErrno
|
|
|
|
else pure 0
|
|
|
|
|
|
|
|
||| Listens on a bound socket.
|
|
|
|
|||
|
|
|
|
||| @sock The socket to listen on.
|
|
|
|
export
|
Back to HasIO, remove MonadIO
Following a fairly detailed discussion on slack, the feeling is
generally that it's better to have a single interface. While precision
is nice, it doesn't appear to buy us anything here. If that turns out to
be wrong, or limiting somehow, we can revisit it later. Also:
- it's easier for backend authors if the type of IO operations is
slightly less restrictive. For example, if it's in HasIO, that limits
alternative implementations, which might be awkward for some
alternative back ends.
- it's one less extra detail to learn. This is minor, but there needs to
be a clear advantage if there's more detail to learn.
- It is difficult to think of an underlying type that can't have a Monad
instance (I have personally never encountered one - if they turns out
to exist, again, we can revisit!)
2020-06-21 21:21:22 +03:00
|
|
|
listen : HasIO io => (sock : Socket) -> io Int
|
2020-05-18 15:59:07 +03:00
|
|
|
listen sock = do
|
2020-07-21 14:30:33 +03:00
|
|
|
listen_res <- primIO $ prim__socket_listen (descriptor sock) BACKLOG
|
2020-05-18 15:59:07 +03:00
|
|
|
if listen_res == (-1)
|
|
|
|
then getErrno
|
|
|
|
else pure 0
|
|
|
|
|
|
|
|
||| Accept a connection on the provided socket.
|
|
|
|
|||
|
|
|
|
||| Returns on failure a `SocketError`
|
|
|
|
||| Returns on success a pairing of:
|
|
|
|
||| + `Socket` :: The socket representing the connection.
|
|
|
|
||| + `SocketAddress` :: The
|
|
|
|
|||
|
|
|
|
||| @sock The socket used to establish connection.
|
|
|
|
export
|
Back to HasIO, remove MonadIO
Following a fairly detailed discussion on slack, the feeling is
generally that it's better to have a single interface. While precision
is nice, it doesn't appear to buy us anything here. If that turns out to
be wrong, or limiting somehow, we can revisit it later. Also:
- it's easier for backend authors if the type of IO operations is
slightly less restrictive. For example, if it's in HasIO, that limits
alternative implementations, which might be awkward for some
alternative back ends.
- it's one less extra detail to learn. This is minor, but there needs to
be a clear advantage if there's more detail to learn.
- It is difficult to think of an underlying type that can't have a Monad
instance (I have personally never encountered one - if they turns out
to exist, again, we can revisit!)
2020-06-21 21:21:22 +03:00
|
|
|
accept : HasIO io
|
2020-06-21 17:25:40 +03:00
|
|
|
=> (sock : Socket)
|
|
|
|
-> io (Either SocketError (Socket, SocketAddress))
|
2020-05-18 15:59:07 +03:00
|
|
|
accept sock = do
|
|
|
|
|
|
|
|
-- We need a pointer to a sockaddr structure. This is then passed into
|
|
|
|
-- idrnet_accept and populated. We can then query it for the SocketAddr and free it.
|
|
|
|
|
2020-07-21 14:30:33 +03:00
|
|
|
sockaddr_ptr <- primIO prim__idrnet_create_sockaddr
|
2020-05-18 15:59:07 +03:00
|
|
|
|
2020-07-21 14:30:33 +03:00
|
|
|
accept_res <- primIO $ prim__idrnet_accept (descriptor sock) sockaddr_ptr
|
2020-05-18 15:59:07 +03:00
|
|
|
if accept_res == (-1)
|
|
|
|
then map Left getErrno
|
|
|
|
else do
|
|
|
|
let (MkSocket _ fam ty p_num) = sock
|
|
|
|
sockaddr <- getSockAddr (SAPtr sockaddr_ptr)
|
|
|
|
sockaddr_free (SAPtr sockaddr_ptr)
|
|
|
|
pure $ Right ((MkSocket accept_res fam ty p_num), sockaddr)
|
|
|
|
|
|
|
|
||| Send data on the specified socket.
|
|
|
|
|||
|
|
|
|
||| Returns on failure a `SocketError`.
|
|
|
|
||| Returns on success the `ResultCode`.
|
|
|
|
|||
|
|
|
|
||| @sock The socket on which to send the message.
|
|
|
|
||| @msg The data to send.
|
|
|
|
export
|
Back to HasIO, remove MonadIO
Following a fairly detailed discussion on slack, the feeling is
generally that it's better to have a single interface. While precision
is nice, it doesn't appear to buy us anything here. If that turns out to
be wrong, or limiting somehow, we can revisit it later. Also:
- it's easier for backend authors if the type of IO operations is
slightly less restrictive. For example, if it's in HasIO, that limits
alternative implementations, which might be awkward for some
alternative back ends.
- it's one less extra detail to learn. This is minor, but there needs to
be a clear advantage if there's more detail to learn.
- It is difficult to think of an underlying type that can't have a Monad
instance (I have personally never encountered one - if they turns out
to exist, again, we can revisit!)
2020-06-21 21:21:22 +03:00
|
|
|
send : HasIO io
|
2020-06-21 17:25:40 +03:00
|
|
|
=> (sock : Socket)
|
2020-05-18 15:59:07 +03:00
|
|
|
-> (msg : String)
|
2020-06-21 17:25:40 +03:00
|
|
|
-> io (Either SocketError ResultCode)
|
2020-05-18 15:59:07 +03:00
|
|
|
send sock dat = do
|
2020-07-21 14:30:33 +03:00
|
|
|
send_res <- primIO $ prim__idrnet_send (descriptor sock) dat
|
2020-05-18 15:59:07 +03:00
|
|
|
|
|
|
|
if send_res == (-1)
|
|
|
|
then map Left getErrno
|
|
|
|
else pure $ Right send_res
|
|
|
|
|
|
|
|
||| Receive data on the specified socket.
|
|
|
|
|||
|
|
|
|
||| Returns on failure a `SocketError`
|
|
|
|
||| Returns on success a pairing of:
|
|
|
|
||| + `String` :: The payload.
|
|
|
|
||| + `ResultCode` :: The result of the underlying function.
|
|
|
|
|||
|
|
|
|
||| @sock The socket on which to receive the message.
|
|
|
|
||| @len How much of the data to receive.
|
|
|
|
export
|
Back to HasIO, remove MonadIO
Following a fairly detailed discussion on slack, the feeling is
generally that it's better to have a single interface. While precision
is nice, it doesn't appear to buy us anything here. If that turns out to
be wrong, or limiting somehow, we can revisit it later. Also:
- it's easier for backend authors if the type of IO operations is
slightly less restrictive. For example, if it's in HasIO, that limits
alternative implementations, which might be awkward for some
alternative back ends.
- it's one less extra detail to learn. This is minor, but there needs to
be a clear advantage if there's more detail to learn.
- It is difficult to think of an underlying type that can't have a Monad
instance (I have personally never encountered one - if they turns out
to exist, again, we can revisit!)
2020-06-21 21:21:22 +03:00
|
|
|
recv : HasIO io
|
2020-06-21 17:25:40 +03:00
|
|
|
=> (sock : Socket)
|
2020-05-18 15:59:07 +03:00
|
|
|
-> (len : ByteLength)
|
2020-06-21 17:25:40 +03:00
|
|
|
-> io (Either SocketError (String, ResultCode))
|
2020-05-18 15:59:07 +03:00
|
|
|
recv sock len = do
|
|
|
|
-- Firstly make the request, get some kind of recv structure which
|
|
|
|
-- contains the result of the recv and possibly the retrieved payload
|
2020-07-21 14:30:33 +03:00
|
|
|
recv_struct_ptr <- primIO $ prim__idrnet_recv (descriptor sock) len
|
|
|
|
recv_res <- primIO $ prim__idrnet_get_recv_res recv_struct_ptr
|
2020-05-18 15:59:07 +03:00
|
|
|
|
|
|
|
if recv_res == (-1)
|
|
|
|
then do
|
|
|
|
errno <- getErrno
|
|
|
|
freeRecvStruct (RSPtr recv_struct_ptr)
|
|
|
|
pure $ Left errno
|
|
|
|
else
|
|
|
|
if recv_res == 0
|
|
|
|
then do
|
|
|
|
freeRecvStruct (RSPtr recv_struct_ptr)
|
|
|
|
pure $ Left 0
|
|
|
|
else do
|
2020-07-21 14:30:33 +03:00
|
|
|
payload <- primIO $ prim__idrnet_get_recv_payload recv_struct_ptr
|
2020-05-18 15:59:07 +03:00
|
|
|
freeRecvStruct (RSPtr recv_struct_ptr)
|
|
|
|
pure $ Right (payload, recv_res)
|
|
|
|
|
|
|
|
||| Receive all the remaining data on the specified socket.
|
|
|
|
|||
|
|
|
|
||| Returns on failure a `SocketError`
|
|
|
|
||| Returns on success the payload `String`
|
|
|
|
|||
|
|
|
|
||| @sock The socket on which to receive the message.
|
|
|
|
export
|
Back to HasIO, remove MonadIO
Following a fairly detailed discussion on slack, the feeling is
generally that it's better to have a single interface. While precision
is nice, it doesn't appear to buy us anything here. If that turns out to
be wrong, or limiting somehow, we can revisit it later. Also:
- it's easier for backend authors if the type of IO operations is
slightly less restrictive. For example, if it's in HasIO, that limits
alternative implementations, which might be awkward for some
alternative back ends.
- it's one less extra detail to learn. This is minor, but there needs to
be a clear advantage if there's more detail to learn.
- It is difficult to think of an underlying type that can't have a Monad
instance (I have personally never encountered one - if they turns out
to exist, again, we can revisit!)
2020-06-21 21:21:22 +03:00
|
|
|
recvAll : HasIO io => (sock : Socket) -> io (Either SocketError String)
|
2020-05-18 15:59:07 +03:00
|
|
|
recvAll sock = recvRec sock [] 64
|
|
|
|
where
|
|
|
|
partial
|
2020-06-21 17:25:40 +03:00
|
|
|
recvRec : Socket -> List String -> ByteLength -> io (Either SocketError String)
|
2020-05-18 15:59:07 +03:00
|
|
|
recvRec sock acc n = do res <- recv sock n
|
|
|
|
case res of
|
|
|
|
Left c => pure (Left c)
|
2020-06-06 21:51:19 +03:00
|
|
|
Right (str, res) => let n' = min (n * 2) 65536 in
|
|
|
|
if res < n then pure (Right $ concat $ reverse $ str :: acc)
|
|
|
|
else recvRec sock (str :: acc) n'
|
2020-05-18 15:59:07 +03:00
|
|
|
|
|
|
|
||| Send a message.
|
|
|
|
|||
|
|
|
|
||| Returns on failure a `SocketError`
|
|
|
|
||| Returns on success the `ResultCode`
|
|
|
|
|||
|
|
|
|
||| @sock The socket on which to send the message.
|
|
|
|
||| @addr Address of the recipient.
|
|
|
|
||| @port The port on which to send the message.
|
|
|
|
||| @msg The message to send.
|
|
|
|
export
|
Back to HasIO, remove MonadIO
Following a fairly detailed discussion on slack, the feeling is
generally that it's better to have a single interface. While precision
is nice, it doesn't appear to buy us anything here. If that turns out to
be wrong, or limiting somehow, we can revisit it later. Also:
- it's easier for backend authors if the type of IO operations is
slightly less restrictive. For example, if it's in HasIO, that limits
alternative implementations, which might be awkward for some
alternative back ends.
- it's one less extra detail to learn. This is minor, but there needs to
be a clear advantage if there's more detail to learn.
- It is difficult to think of an underlying type that can't have a Monad
instance (I have personally never encountered one - if they turns out
to exist, again, we can revisit!)
2020-06-21 21:21:22 +03:00
|
|
|
sendTo : HasIO io
|
2020-06-21 17:25:40 +03:00
|
|
|
=> (sock : Socket)
|
2020-05-18 15:59:07 +03:00
|
|
|
-> (addr : SocketAddress)
|
|
|
|
-> (port : Port)
|
|
|
|
-> (msg : String)
|
2020-06-21 17:25:40 +03:00
|
|
|
-> io (Either SocketError ByteLength)
|
2020-05-18 15:59:07 +03:00
|
|
|
sendTo sock addr p dat = do
|
2020-07-21 14:30:33 +03:00
|
|
|
sendto_res <- primIO $ prim__idrnet_sendto
|
2020-05-20 22:09:56 +03:00
|
|
|
(descriptor sock) dat (show addr) p (toCode $ family sock)
|
2020-05-18 15:59:07 +03:00
|
|
|
|
|
|
|
if sendto_res == (-1)
|
|
|
|
then map Left getErrno
|
|
|
|
else pure $ Right sendto_res
|
|
|
|
|
|
|
|
||| Receive a message.
|
|
|
|
|||
|
|
|
|
||| Returns on failure a `SocketError`.
|
|
|
|
||| Returns on success a triple of
|
|
|
|
||| + `UDPAddrInfo` :: The address of the sender.
|
|
|
|
||| + `String` :: The payload.
|
|
|
|
||| + `Int` :: Result value from underlying function.
|
|
|
|
|||
|
|
|
|
||| @sock The channel on which to receive.
|
|
|
|
||| @len Size of the expected message.
|
|
|
|
|||
|
|
|
|
export
|
Back to HasIO, remove MonadIO
Following a fairly detailed discussion on slack, the feeling is
generally that it's better to have a single interface. While precision
is nice, it doesn't appear to buy us anything here. If that turns out to
be wrong, or limiting somehow, we can revisit it later. Also:
- it's easier for backend authors if the type of IO operations is
slightly less restrictive. For example, if it's in HasIO, that limits
alternative implementations, which might be awkward for some
alternative back ends.
- it's one less extra detail to learn. This is minor, but there needs to
be a clear advantage if there's more detail to learn.
- It is difficult to think of an underlying type that can't have a Monad
instance (I have personally never encountered one - if they turns out
to exist, again, we can revisit!)
2020-06-21 21:21:22 +03:00
|
|
|
recvFrom : HasIO io
|
2020-06-21 17:25:40 +03:00
|
|
|
=> (sock : Socket)
|
2020-05-18 15:59:07 +03:00
|
|
|
-> (len : ByteLength)
|
2020-06-21 17:25:40 +03:00
|
|
|
-> io (Either SocketError (UDPAddrInfo, String, ResultCode))
|
2020-05-18 15:59:07 +03:00
|
|
|
recvFrom sock bl = do
|
2020-07-21 14:30:33 +03:00
|
|
|
recv_ptr <- primIO $ prim__idrnet_recvfrom
|
|
|
|
(descriptor sock) bl
|
2020-05-18 15:59:07 +03:00
|
|
|
|
|
|
|
let recv_ptr' = RFPtr recv_ptr
|
|
|
|
isNull <- (nullPtr recv_ptr)
|
|
|
|
if isNull
|
|
|
|
then map Left getErrno
|
|
|
|
else do
|
2020-07-21 14:30:33 +03:00
|
|
|
result <- primIO $ prim__idrnet_get_recvfrom_res recv_ptr
|
2020-05-18 15:59:07 +03:00
|
|
|
if result == -1
|
|
|
|
then do
|
|
|
|
freeRecvfromStruct recv_ptr'
|
|
|
|
map Left getErrno
|
|
|
|
else do
|
|
|
|
payload <- foreignGetRecvfromPayload recv_ptr'
|
|
|
|
port <- foreignGetRecvfromPort recv_ptr'
|
|
|
|
addr <- foreignGetRecvfromAddr recv_ptr'
|
|
|
|
freeRecvfromStruct recv_ptr'
|
|
|
|
pure $ Right (MkUDPAddrInfo addr port, payload, result)
|