summaryrefslogtreecommitdiff
path: root/doc/xs_recvmsg.txt
blob: 4a88177ab55304583b610eabc0dc497d5cf5507d (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
xs_recvmsg(3)
=============


NAME
----
xs_recvmsg - receive a message part from a socket (zero-copy)


SYNOPSIS
--------
*int xs_recvmsg (void '*socket', xs_msg_t '*msg', int 'flags');*


DESCRIPTION
-----------
The _xs_recvmsg()_ function shall receive a message part from the socket
referenced by the 'socket' argument and store it in the message referenced by
the 'msg' argument. Any content previously stored in 'msg' shall be properly
deallocated. If there are no message parts available on the specified 'socket'
the _xs_recvmsg()_ function shall block until the request can be satisfied.
The 'flags' argument is a combination of the flags defined below:

*XS_DONTWAIT*::
Specifies that the operation should be performed in non-blocking mode. If there
are no messages available on the specified 'socket', the _xs_recvmsg()_
function shall fail with 'errno' set to EAGAIN.


Multi-part messages
~~~~~~~~~~~~~~~~~~~
A Crossroads message is composed of 1 or more message parts. Each message
part is an independent 'xs_msg_t' in its own right. Crossroads ensures atomic
delivery of messages; peers shall receive either all _message parts_ of a
message or none at all. The total number of message parts is unlimited except
by available memory.

An application that processes multipart messages must use the _XS_RCVMORE_
linkxs:xs_getsockopt[3] option after calling _xs_recvmsg()_ to determine if
there are further parts to receive.


RETURN VALUE
------------
The _xs_recvmsg()_ function shall return the number of bytes in the
received message if successful. Otherwise it shall return `-1` and set
'errno' to one of the values defined below.


ERRORS
------
*EAGAIN*::
Non-blocking mode was requested and no messages are available at the moment.
*ENOTSUP*::
The _xs_recvmsg()_ operation is not supported by this socket type.
*EFSM*::
The _xs_recvmsg()_ operation cannot be performed on this socket at the moment
due to the socket not being in the appropriate state.  This error may occur with
socket types that switch between several states, such as XS_REP.  See the
_messaging patterns_ section of linkxs:xs_socket[3] for more information.
*ETERM*::
The 'context' associated with the specified 'socket' was terminated.
*ENOTSOCK*::
The provided 'socket' was invalid.
*EINTR*::
The operation was interrupted by delivery of a signal before a message was
available.
*EFAULT*::
The message passed to the function was invalid.


EXAMPLE
-------
.Receiving a message from a socket
----
/* Create an empty message */
xs_msg_t msg;
int rc = xs_msg_init (&msg);
assert (rc == 0);
/* Block until a message is available to be received from socket */
rc = xs_recvmsg (socket, &msg, 0);
assert (rc != -1);
/* Release message */
xs_msg_close (&msg);
----

.Receiving a multi-part message
----
int64_t more;
size_t more_size = sizeof more;
do {
    /* Create an empty message to hold the message part */
    xs_msg_t part;
    int rc = xs_msg_init (&part);
    assert (rc == 0);
    /* Block until a message is available to be received from socket */
    rc = xs_recvmsg (socket, &part, 0);
    assert (rc != -1);
    /* Determine if more message parts are to follow */
    rc = xs_getsockopt (socket, XS_RCVMORE, &more, &more_size);
    assert (rc == 0);
    xs_msg_close (&part);
} while (more);
----


SEE ALSO
--------
Applications that do not require zero-copy messaging can use the simpler
linkxs:xs_recv[3] instead of _xs_recvmsg()_.

linkxs:xs_sendmsg[3]
linkxs:xs_getsockopt[3]
linkxs:xs_socket[7]
linkxs:xs[7]


AUTHORS
-------
This man page was written by Martin Sustrik <sustrik@250bpm.com>, Martin
Lucina <martin@lucina.net> and Pieter Hintjens <ph@imatix.com>.