1e7e4330 |
1 | .\" -*-nroff-*- |
2 | .TH pkbuf 3 "16 July 2000" mLib |
3 | .SH "NAME" |
4 | pkbuf \- split packets out of asynchronously received blocks |
5 | .\" @pkbuf_flush |
6 | .\" @pkbuf_close |
7 | .\" @pkbuf_free |
8 | .\" @pkbuf_snarf |
9 | .\" @pkbuf_want |
10 | .\" @pkbuf_init |
11 | .\" @pkbuf_destroy |
12 | .SH "SYNOPSIS" |
13 | .nf |
14 | .B "#include <mLib/pkbuf.h>" |
15 | |
16 | .BI "void pkbuf_flush(pkbuf *" pk ", octet *" p ", size_t " len ); |
17 | .BI "void pkbuf_close(pkbuf *" pk ); |
18 | .BI "size_t pkbuf_free(pkbuf *" pk ", octet **" p ); |
19 | .BI "void pkbuf_snarf(pkbuf *" pk ", const void *" p ", size_t " sz ); |
20 | .BI "void pkbuf_want(pkbuf *" pk ", size_t " want ); |
21 | .BI "void pkbuf_init(pkbuf *" pk , |
22 | .BI " void (*" func ")(octet *" b ", size_t " sz ", pkbuf *" pk , |
23 | .BI " size_t *" keep ", void *" p ), |
24 | .BI " void *" pk ); |
25 | .BI "void pkbuf_destroy(pkbuf *" pk ); |
26 | .fi |
27 | .SH "DESCRIPTION" |
28 | The declarations in |
29 | .B <mLib/pkbuf.h> |
30 | implement a |
31 | .IR "packet buffer" . |
32 | Given unpredictably-sized chunks of data, the packet buffer extracts |
33 | completed packets of data, with sizes ascertained by a handler |
34 | function. |
35 | .PP |
36 | The state of a packet buffer is stored in an object of type |
37 | .BR pkbuf . |
38 | This is a structure which must be allocated by the caller. The |
39 | structure should normally be considered opaque (see the section on |
40 | .B Disablement |
41 | for an exception to this). |
42 | .SS "Initialization and finalization" |
43 | The function |
44 | .B pkbuf_init |
45 | initializes a packet buffer ready for use. It is given three arguments: |
46 | .TP |
47 | .BI "pkbuf *" pk |
48 | A pointer to the block of memory to use for the packet buffer. The packet |
49 | buffer will allocate memory to store incoming data automatically: this |
50 | structure just contains bookkeeping information. |
51 | .TP |
52 | .nf |
53 | .BI "void (*" func ")(octet *" b ", size_t " sz ", pkbuf *" p , |
54 | .BI " size_t *" keep ", void *" p ) |
55 | .fi |
56 | The |
57 | .I packet-handler |
58 | function to which the packet buffer should pass packets of data when |
59 | they're received. |
60 | .TP |
61 | .BI "void *" p |
62 | A pointer argument to be passed to the function when a packet arrives. |
63 | .PP |
64 | By default, the buffer is |
65 | allocated from the current arena, |
66 | .BR arena_global (3); |
67 | this may be changed by altering the buffer's |
68 | .B a |
69 | member to refer to a different arena at any time when the buffer is |
70 | unallocated. |
71 | .PP |
72 | A packet buffer must be destroyed after use by calling |
73 | .BR pkbuf_destroy , |
74 | passing it the address of the buffer block. |
75 | .SS "Inserting data into the buffer" |
76 | There are two interfaces for inserting data into the buffer. One's much |
77 | simpler than the other, although it's less expressive. |
78 | .PP |
79 | The simple interface is |
80 | .BR pkbuf_snarf . |
81 | This function is given three arguments: a pointer |
82 | .I pk |
83 | to a packet buffer structure; a pointer |
84 | .I p |
85 | to a chunk of data to read; and the size |
86 | .I sz |
87 | of the chunk of data. The data is pushed through the packet buffer and |
88 | any complete packets are passed on to the packet handler. |
89 | .PP |
90 | The complex interface is the pair of functions |
91 | .I pkbuf_free |
92 | and |
93 | .IR pkbuf_flush . |
94 | .PP |
95 | The |
96 | .B pkbuf_free |
97 | function returns the address and size of a free portion of the packet |
98 | buffer's memory into which data may be written. The function is passed |
99 | the address |
100 | .I pk |
101 | of the packet buffer. Its result is the size of the free area, and it |
102 | writes the base address of this free space to the location pointed to by |
103 | the argument |
104 | .IR p . |
105 | The caller's data must be written to ascending memory locations starting |
106 | at |
107 | .BI * p |
108 | and no data may be written beyond the end of the free space. However, |
109 | it isn't necessary to completely fill the buffer. |
110 | .PP |
111 | Once the free area has had some data written to it, |
112 | .B pkbuf_flush |
113 | is called to examine the new data and break it into packets. This is |
114 | given three arguments: |
115 | .TP |
116 | .BI "pkbuf *" pk |
117 | The address of the packet buffer. |
118 | .TP |
119 | .BI "octet *" p |
120 | The address at which the new data has been written. This must be the |
121 | base address returned from |
122 | .BR pkbuf_free . |
123 | .TP |
124 | .BI "size_t " len |
125 | The number of bytes which have been written to the buffer. |
126 | .PP |
127 | The |
128 | .B pkbuf_flush |
129 | function breaks the new data into packets as described below, and passes |
130 | each one in turn to the packet-handler function. |
131 | .PP |
132 | The |
133 | .B pkbuf_snarf |
134 | function is trivially implemented in terms of the more complex |
135 | .B pkbuf_free / pkbuf_flush |
136 | interface. |
137 | .SS "Packet breaking and the handler fucntion" |
138 | The function |
139 | .B pkbuf_want |
140 | is used to inform the packet buffer of the expected length of the next |
141 | packet. It is given the pointer |
142 | .I pk |
143 | to the packet buffer and a size |
144 | .I sz |
145 | of the packet. |
146 | .PP |
147 | When enough data has arrived, the packet-handler function is called, and |
148 | passed: |
149 | .TP |
150 | .BI "octet *" b |
151 | A pointer to the packet data in the buffer, or zero to signify |
152 | end-of-file. |
153 | .TP |
154 | .BI "size_t " sz |
155 | The size of the packet, as previously configured via |
156 | .BR pkbuf_want . |
157 | .TP |
158 | .BI "pkbuf *" pk |
159 | A pointer to the packet buffer. |
160 | .TP |
161 | .BI "size_t *" keep |
162 | A location in which to store the number of bytes of the current packet |
163 | to be retained. The bytes kept are from the end of the current packet: |
164 | if you want to keep bytes from the beginning of the packet, you should |
165 | move them into the right place. |
166 | .TP |
167 | .BI "void *" p |
168 | The pointer which was set up in the call to |
169 | .BR pkbuf_init . |
170 | .PP |
171 | .SS "Flushing the remaining data" |
172 | When the client program knows that there's no more data arriving (for |
173 | example, an end-of-file condition exists on its data source) it should |
174 | call the function |
175 | .BR pkbuf_close . |
176 | This will call the handler one final time with a null pointer to inform |
177 | it of the end-of-file. |
178 | .SS "Disablement" |
179 | The packet buffer is intended to be used in higher-level program |
180 | objects, such as the packet selector described in |
181 | .BR selpk (3). |
182 | Unfortunately, a concept from this high level needs to exist at the |
183 | packet buffer level, which complicates the description somewhat. The |
184 | idea is that, when a packet-handler attached to some higher-level object |
185 | decides that it's read enough, it can |
186 | .I disable |
187 | the object so that it doesn't see any more data. |
188 | .PP |
189 | Clearly, since an |
190 | .B pkbuf_flush |
191 | call can emit more than one packet, so it must be aware that the packet |
192 | handler isn't interested in any more packet. However, this fact must |
193 | also be signalled to the higher-level object so that it can detach |
194 | itself from its data source. |
195 | .PP |
196 | Rather than invent some complex interface for this, the packet buffer |
197 | exports one of its structure members, |
198 | .BR flags . |
199 | A higher-level object wishing to disable the packet buffer simply clears |
200 | the bit |
201 | .B PKBUF_ENABLE |
202 | in the flags word. |
203 | .PP |
204 | Disabling a buffer causes an immediate return from |
205 | .BR pkbuf_flush . |
206 | However, it is not permitted for the functions |
207 | .B pkbuf_flush |
208 | or |
209 | .B pkbuf_close |
210 | to be called on a disabled buffer. (This condition isn't checked for; |
211 | it'll just do the wrong thing.) Furthermore, the |
212 | .B pkbuf_snarf |
213 | function does not handle disablement at all, because it would complicate |
214 | the interface so much that it wouldn't have any advantage over the more |
215 | general |
216 | .BR pkbuf_free / pkbuf_flush . |
217 | .SH "SEE ALSO" |
218 | .BR lbuf (3), |
219 | .BR selpk (3), |
220 | .BR mLib (3). |
221 | .SH "AUTHOR" |
222 | Mark Wooding, <mdw@nsict.org> |