BSD Sockets API: Basic blocking API

[zephyrbot]

Reported by Paul Sokolovsky:

"As an application developer, familiar with BSD Sockets API (part of POSIX), I would like to develop, or port existing, simple (blocking sockets mode) networking applications using this API, on Zephyr RTOS. I would like the behavior of API calls to be as close as possible to POSIX. All of UDP, TCP, IPv4, IPv6 should be supported."

API calls planned to be implemented:

• socket()
• close() (for sockets)
• connect() (blocking)
• bind()
• listen()
• accept() (blocking)
• send() (blocking)
• recv() (blocking)
• getaddrinfo()

There should be simple client and simple server sample applications to demonstrate the functionality, similar to echo_client/echo_server samples for native API.

(Imported from Jira ZEP-2226)

[zephyrbot]

by Paul Sokolovsky:

Patchset was submitted: #498

[zephyrbot]

by Paul Sokolovsky:

This story was implemented and merged.

[zephyrbot]

by Paul Sokolovsky:

There's a test: tests/net/socket/udp/ , and a sample: samples/net/socket_echo/.

[zephyrbot]

by gurucharan p:

The current sample implementation in samples/net/sockets/echo/ seems to be supported only for TCP and IPv4 and it is working fine in this. But I would like to know if we have any plans of implementing/expanding the code to further support for UDP and IPv6 too like in the sample code echo_server

Also the current sample is working fine for the first time,but failing to be connected and send and recv the packets from the 2nd time onwards on TCP socket

[zephyrbot]

by Paul Sokolovsky:

The BSD Sockets subsystem supports UDP and IPv6. However, the purpose of samples/net/sockets/echo/ sample is to show simple, easy to follow sockets code which portable between POSIX (Linux) and Zephyr. So, I don't expect that particular sample to expanded.

The coverage tests (vs samples) should be expanded however, and there's a simple IPv4 UDP test in tests/net/socket/udp/. Further expansion is however blocked on inflexibility of testing system (literally, testing network functionality requires a network interface, but sanitycheck doesn't provide one), so that's the subject of future work.

[zephyrbot]

by Paul Sokolovsky:

Also the current sample is working fine for the first time,but failing to be connected and send and recv the packets from the 2nd time onwards on TCP socket

Please submit a separate ticket with details of your testing environment and steps to reproduce. Thanks.

[zephyrbot]

by gurucharan p:

It seems there was a problem with the application at my end.The sample application works fine for packet transfer in TCP.

[zephyrbot]

by Paul Sokolovsky:

Thanks for the follow-up. I by now did quite extensive testing on qemu_x86 (SLIP), frdm_k64f (Ethernet) and 96b_carbon (6lowpan/BLE), and never saw that issue, multiple connections worked well for me.

Of the related note, I actually extended non-blocking sample (so, mostly relates to ZEP-2227), sockets/echo_async to support both IPv4 and IPv6: #1186 . (sockets/echo stays IPv4-only, as there's no easy way to extend it anyway.)

[zephyrbot]

by Chandrakala Kempanna:

gurucharan p Please close the Jira if found working

[zephyrbot]

by gurucharan p:

It seems this issue has been fixed with commit ID: eb5d6fc

So closing the Jira.

[zephyrbot]

Related to GH-3706