The POSIX_MAX_FDS option does not correspond to any standard POSIX option. It was used to define the size of the file descriptor table, which is by no means exclusively used by POSIX (also net, fs, ...). POSIX_MAX_FDS is being deprecated in order to ensure that Zephyr's POSIX Kconfig variables correspond to those defined in the specification, as of IEEE 1003.1-2017. Namely, POSIX_OPEN_MAX. CONFIG_POSIX_MAX_OPEN_FILES is being deprecated for the same reason. To mitigate any possible layering violations, that option is not user selectable. It tracks the newly added CONFIG_ZVFS_OPEN_MAX option, which is native to Zephyr. With this deprecation, we introduce the following Kconfig options that map directly to standard POSIX Option Groups by simply removing "CONFIG_": * CONFIG_POSIX_DEVICE_IO Similarly, with this deprecation, we introduce the following Kconfig options that map directly to standard POSIX Options by simply removing "CONFIG": * CONFIG_POSIX_OPEN_MAX In order to maintain parity with the current feature set, we introduce the following Kconfig options. * CONFIG_POSIX_DEVICE_IO_ALIAS_CLOSE * CONFIG_POSIX_DEVICE_IO_ALIAS_OPEN * CONFIG_POSIX_DEVICE_IO_ALIAS_READ * CONFIG_POSIX_DEVICE_IO_ALIAS_WRITE Gate open(), close(), read(), and write() via the CONFIG_POSIX_DEVICE_IO Kconfig option and move implementations into device_io.c, to be conformant with the spec. Lastly, stage function names for upcoming ZVFS work, to be completed as part of the LTSv3 Roadmap (e.g. zvfs_open(), ..). Signed-off-by: Chris Friedt <cfriedt@tenstorrent.com> |
||
|---|---|---|
| .. | ||
| src | ||
| CMakeLists.txt | ||
| overlay-e1000.conf | ||
| prj.conf | ||
| README.rst | ||
| sample.yaml | ||
.. zephyr:code-sample:: sockets-service-echo
:name: Echo server (service)
:relevant-api: bsd_sockets
Implements a simple IPv4/IPv6 TCP echo server using BSD sockets and socket service API.
Overview
********
The sockets/echo_service sample application for Zephyr implements a TCP echo
server supporting both IPv4 and IPv6 and using a BSD Sockets compatible API.
The purpose of this sample is to show how to use socket service API.
The socket service is a concept where many blocking sockets can be listened by
one thread, and which can then trigger a callback if there is activity in the set
of sockets. This saves memory as only one thread needs to be created in the
system.
The application supports IPv4 and IPv6, and both UDP and TCP are also supported.
The source code for this sample application can be found at:
:zephyr_file:`samples/net/sockets/echo_service`.
Requirements
************
- :ref:`networking_with_host`
- or, a board with hardware networking
Building and Running
********************
Build the Zephyr version of the sockets/echo_service application like this:
.. zephyr-app-commands::
:zephyr-app: samples/net/sockets/echo_service
:board: <board_to_use>
:goals: build
:compact:
After the sample starts, it expects connections at 192.0.2.1, or 2001:db8::1
and port 4242.
The easiest way to connect is:
.. code-block:: console
$ telnet 192.0.2.1 4242
After a connection is made, the application will echo back any line sent
to it. The application implements a single-threaded server using blocking
sockets, and currently is only implemented to serve only one client connection
at time. After the current client disconnects, the next connection can proceed.