Lines Matching refs:data

182 --- Sending TCP data
184 TCP data is sent by enqueueing the data with a call to
185 tcp_write(). When the data is successfully transmitted to the remote
192   Enqueues the data pointed to by the argument dataptr. The length of
193   the data is passed as the len parameter. The apiflags can be one or more of:
195     for the data to be copied into. If this flag is not given, no new memory
196     should be allocated and the data should only be referenced by pointer. This
197     also means that the memory behind dataptr must not change until the data is
199   - TCP_WRITE_FLAG_MORE: indicates that more data follows. If this is given,
204   of the data exceeds the current send buffer size or if the length of
210   most tcp_sndbuf() bytes of data. If the function returns ERR_MEM,
212   data has been successfully received by the other host and try again.
218   Specifies the callback function that should be called when data has
224 --- Receiving TCP data
226 TCP data reception is callback based - an application specified
227 callback function is called when new data arrives. When the
228 application has taken the data, it has to call the tcp_recved()
236   Sets the callback function that will be called when new data
245   Must be called when the application has received the data. The len
246   argument indicates the length of the received data.
251 When a connection is idle (i.e., no data is either transmitted or
496 To achieve zero-copy on transmit, the data passed to the raw API must
498 when the packets have been enqueued for sending, data must be kept stable
504 For no-copy pbufs (PBUF_ROM/PBUF_REF), data must be kept unchanged, too,
505 but the stack/driver will/must copy PBUF_REF'ed data when enqueueing, while
506 PBUF_ROM-pbufs are just enqueued (as ROM-data is expected to never change).
508 Also, data passed to tcp_write without the copy-flag must not be changed!
510 Therefore, be careful which type of PBUF you use and if you copy TCP data