TCP send() on server socket

Hello Richard,

As far as I remember, both the TCP "send()" and "recv()" functions block a thread. Normally in a server implementation, you receive something from the client, process it and then send data back to the client. So you could use the same thread to "recv" and "send".

From the TCP Echo example, you could modify the "tcpWorker" task such that after recv() is executed, processing of the data is done in the same task and then send() is called. Alternatively the processing of the data could be done by another task, in which case the "tcpWorker" task will wait after recv() is executed (with a semaphore), for the processing of the other task to complete (which would be indicated by releasing the semaphore). The "tcpWorker" would then call send().

Does you server need to send() irrespective to recv()? If so, could you explain the flow?

Alternatively a different tasks could be used to "send" and "recv", but this would require inter task communication (to share the same socket and other resources along with when to send and when to recv), which could be complicated.

Thanks,
Sai

Richard Bland said:

The recv() blocks the thread. I can set this to unblocking, but then the send() may get called with length 0, and what makes the thread wait?

Using the BSD socket API under Unix, it is possible to have a single thread perform IO on multiple sockets by setting the sockets to non-blocking and then using the select() or poll() for one or more sockets to be readable (or read error pending) or  writable (or send error pending).

Unlike Unix TI-RTOS doesn't have built-in support for file descriptors. However, the TI Network Developer's Kit does have a File Descriptor Environment and BSD Sockets Compatibility API Layer to give the equivalent of the select() and poll() functions. See the Sockets and Stream IO API chapter of www.ti.com/lit/pdf/spru524‎