For stream-based protocols (TCP), adding less data than requested
("short write") is generally not a problem - the rest of data can
be sent in the next packet. So, make net_pkt_append() return length
of written data instead of just bool flag, which makes it closer
to the behavior of POSIX send()/write() calls.
There're many users of older net_pkt_append() in the codebase
however, so net_pkt_append_all() convenience function is added which
keeps returning a boolean flag. All current users were converted to
this function, except for two:
samples/net/http_server/src/ssl_utils.c
samples/net/mbedtls_sslclient/src/tcp.c
Both are related to TLS and implement mbedTLS "tx callback", which
follows POSIX short-write semantics. Both cases also had a code to
workaround previous boolean-only behavior of net_pkt_append() - after
calling it, they measured length of the actual data added (but only
in case of successful return of net_pkt_append(), so that didn't
really help). So, these 2 cases are already improved.
Jira: ZEP-1984
Change-Id: Ibaf7c029b15e91b516d73dab3612eed190ee982b
Signed-off-by: Paul Sokolovsky <paul.sokolovsky@linaro.org>
Convert code to use u{8,16,32,64}_t and s{8,16,32,64}_t instead of C99
integer types.
Jira: ZEP-2051
Change-Id: I4ec03eb2183d59ef86ea2c20d956e5d272656837
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
- net_pkt becomes a stand-alone structure with network packet meta
information.
- network packet data is still managed through net_buf, mostly named
'frag'.
- net_pkt memory management is done through k_mem_slab
- function got introduced or relevantly renamed to target eithe net_pkt
or net_buf fragments.
- net_buf's sent_list ends up in net_pkt now, and thus helps to save
memory when TCP is enabled.
Change-Id: Ibd5c17df4f75891dec79db723a4c9fc704eb843d
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
There have been long lasting confusion between net_buf and net_nbuf.
While the first is actually a buffer, the second one is not. It's a
network buffer descriptor. More precisely it provides meta data about a
network packet, and holds the chain of buffer fragments made of net_buf.
Thus renaming net_nbuf to net_pkt and all names around it as well
(function, Kconfig option, ..).
Though net_pkt if the new name, it still inherit its logic from net_buf.
'
This patch is the first of a serie that will separate completely net_pkt
from net_buf.
Change-Id: Iecb32d2a0d8f4647692e5328e54b5c35454194cd
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
This is a start to move away from the C99 {u}int{8,16,32,64}_t types to
Zephyr defined u{8,16,32,64}_t and s{8,16,32,64}_t. This allows Zephyr
to define the sized types in a consistent manor across all the
architectures we support and not conflict with what various compilers
and libc might do with regards to the C99 types.
We introduce <zephyr/types.h> as part of this and have it include
<stdint.h> for now until we transition all the code away from the C99
types.
We go with u{8,16,32,64}_t and s{8,16,32,64}_t as there are some
existing variables defined u8 & u16 as well as to be consistent with
Zephyr naming conventions.
Jira: ZEP-2051
Change-Id: I451fed0623b029d65866622e478225dfab2c0ca8
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
This addresses the issues found by QA in ZEP-1012 and clarify the
documentated behavior as described in ZEP-1859.
Change-Id: I602e5749db7f6f44cf5be449b8e6f0d2ba66b69b
Signed-off-by: Leandro Pereira <leandro.pereira@intel.com>
s/SAMPLES/APP for name shortening. Applying the change where relevant.
Not only IP addresse will be available as samples settings there but
also IEEE 802.15.4 channel, pan_id, and more for instance.
Change-Id: I05dd24989bd0c804d9588092d67044a3e063bc88
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
NATS is a publisher/subscriber protocol implemented on top of TCP. It
is specified in [1], and this is a sample implementation for Zephyr
using the new IP stack. The API is loosely based off of [2].
With this sample, it's possible to subscribe/unsubscribe to a given
subject, and be notified of changes asynchronously. In order to
conserve resources, the implementation does not keep its own track of
subscribed subjects; that must be performed by the application itself,
so it ignore unknown/undesired subjects.
TLS is not supported yet, although basic auth is. The client will
indicate if it supports username/password if a certain callback is set
in the struct nats. This callback will then be called, and the user
must copy the username/password to the supplied user/pass buffers.
Content might be also published for a given subject.
The sample application lets one observe the subject "led0", and turn it
"on", "off", or "toggle" its value. Changing the value will, if
supported, act on a status LED on the development board. The new
status will be published.
Also worth noting is that most of the networking and GPIO boilerplate
has been shamelessly copied from the IRC bot example. (Curiously, both
protocols are similar.)
[1] http://nats.io/documentation/internals/nats-protocol/
[2] https://github.com/nats-io/go-nats
Jira: ZEP-1012
Change-Id: I204adc61c4c533661eacfb8c28c1c08870debd91
Signed-off-by: Leandro Pereira <leandro.pereira@intel.com>
Andrew Boie