Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

sock: doc fixes #5884

Merged
merged 1 commit into from
Oct 4, 2016
Merged

sock: doc fixes #5884

merged 1 commit into from
Oct 4, 2016

Conversation

miri64
Copy link
Member

@miri64 miri64 commented Sep 28, 2016

Fixes the comments in #5758.

@miri64 miri64 added Type: enhancement The issue suggests enhanceable parts / The PR enhances parts of the codebase / documentation Area: network Area: Networking Area: doc Area: Documentation labels Sep 28, 2016
@miri64
Copy link
Member Author

miri64 commented Sep 28, 2016

Also includes the HOWTOs requested by @emmanuelsearch.

Copy link
Contributor

@aabadie aabadie left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I had a "brief" look at this one and put some comments (typo, rephrasing). Good job !

* they serve as a common API that connects application- and network stack code.
* This module provides a set of functions to establish connections or send and
* receive datagrams using different types of protocols. Together, they serve as
* an API allows an application or library to connect to a network.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

that allows or allowing

* Implementors Notes
* ==================
* ### Type definition
* For simplicity and modularity this API doesn't put any restriction of the
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

on the

* ### Type definition
* For simplicity and modularity this API doesn't put any restriction of the
* actual implementation of the type. For example, one implementation might
* choose to have all `sock` types have a common base class or use the raw IP
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

types having

* res = sock_ip_send(NULL, data, data_len, PROTNUM, &remote);
* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
*
* With `data` being the data send, `data_len` the length of `data`, `PROTNUM`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

data sent

* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
*
* With `data` being the data send, `data_len` the length of `data`, `PROTNUM`
* the next header number for the send packet and `remote` the remote end point
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sent packet

* }
* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
*
* We then create a remote end point for the link-local all nodes multicast
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not sure I correctly understand this.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you tell me how you understand it I maybe can clear that up. As is the sentence seems straight forward to me... :-/

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if I understand well (I hope I do ;) ), I would rephrase like this :
create a remote end point with the link-local multicast address of all nodes and send

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not completely. It creates a remote end point with the link-local all-nodes multicast address (which is a defined address (ff02::1) and is called as such)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Better now?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, thanks for the clarification :)

* @return -EAFNOSUPPORT, if `local != NULL` or `remote != NULL` and
* sock_ip_ep_t::family of @p local or @p remote is not supported.
* @return -EINVAL, if `proto` is not supported or if sock_ip_ep_t::netif of
* @p local or @p remote is not a valid interface or contradict each
* other (i.e. `(local->netif != remote->netif) &&
* ((local->netif != SOCK_ADDR_ANY_NETIF) ||
* (remote->netif != SOCK_ADDR_ANY_NETIF))` if neither is `NULL`).
* @return -ENOMEM, if the stack can't provide enough resources for `sock` to
* be created.
* @return -ENOMEM, if not enough resources for `sock` to be created can be
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

strange rephrasing ;)

Copy link
Contributor

@aabadie aabadie Sep 28, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe ... not enough resources can be provided for sock to be created ?

* uint8_t buf[128];
* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
*
* To be able to listen for incoming packets we want to bind the sock so we need
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we want to bind the sock so we need, etc
=> we bind the sock by setting a local end point with a port ?

* }
* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
*
* We then wait indefinitely for an incoming message in `buf` from `remote`.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think using 'we' when explaining the behavior of the code should be replaced with something more non personal.
Example:
The program then wait indefinitely for an incoming message...

* With `data` being the data send, `data_len` the length of `data` and `remote`
* the remote end point the packet is to be sent.
*
* To see some other utilization we look at a more complex example in form of
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

usage

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

miri64 added a commit to miri64/RIOT that referenced this pull request Sep 28, 2016
@miri64
Copy link
Member Author

miri64 commented Sep 28, 2016

Applied requested changes.

* choose to have all sock types have a common base class or use the raw IP
* sock type to send e.g. UDP packets, while others will keep them
* completely separate from each other.
* Note that there might be no relation between the different `sock` types.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you think users might try that?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

People tried it with conn so why wouldn't they try it with sock?

* The actual code very much depends on the used `sock` type. Please refer to
* their documentation for specific examples.
*
* Implementors Notes
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Implementors -> implementor?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a caption... Why should I remove the capitalization?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed.

@kaspar030
Copy link
Contributor

Implementors Notes

This is a caption... Why should I remove the capitalization?

just remove the plural s at the end of Implementors, capital I is fine.

@kaspar030
Copy link
Contributor

People tried it with conn so why wouldn't they try it with sock?

Someone tried to re-cast the objects into each other?

@miri64
Copy link
Member Author

miri64 commented Sep 28, 2016

just remove the plural s at the end of Implementors, capital I is fine.

oops I actually overlooked that.

@miri64
Copy link
Member Author

miri64 commented Sep 28, 2016

People tried it with conn so why wouldn't they try it with sock?

Someone tried to re-cast the objects into each other?

Yes some testers get funny ideas when you do not explicitly state that a behavior is forbidden ;-). And actually I can understand that when you come from the socket world. Also: casting sock_udp_t to gnrc_ip_t and vice-versa makes also sense to a degree.

@miri64
Copy link
Member Author

miri64 commented Sep 28, 2016

Mind you, they didn't cast a conn that was already established, but used the same type for different operations, after the previous operation was finished.

@immesys
Copy link
Contributor

immesys commented Sep 29, 2016

I just tried testing this and I get a missing "sock_types.h' from udp.h:198, I have gnrc_sock_udp and gnrc_ipv6_default included. I also cannot find sock_types.h anywhere in the codebase. Any tips?

@immesys
Copy link
Contributor

immesys commented Sep 29, 2016

My humblest apologies, I did not see #5772.

@miri64
Copy link
Member Author

miri64 commented Oct 4, 2016

Ping?

Copy link
Contributor

@aabadie aabadie left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks like a good documentation with good examples.

@miri64 miri64 added the CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR label Oct 4, 2016
@miri64
Copy link
Member Author

miri64 commented Oct 4, 2016

@aabadie was that an ACK?

@aabadie
Copy link
Contributor

aabadie commented Oct 4, 2016

@miri64, Murdock is asking for squashing. Then I'll give an ACK.

@miri64
Copy link
Member Author

miri64 commented Oct 4, 2016

Squashed.

@miri64
Copy link
Member Author

miri64 commented Oct 4, 2016

Murdock is happy 😀

@aabadie
Copy link
Contributor

aabadie commented Oct 4, 2016

ACK and Go !

@aabadie aabadie merged commit b016fb4 into RIOT-OS:master Oct 4, 2016
@miri64 miri64 deleted the sock/doc/fix branch October 4, 2016 16:33
@miri64 miri64 mentioned this pull request Oct 4, 2016
5 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area: doc Area: Documentation Area: network Area: Networking CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR Type: enhancement The issue suggests enhanceable parts / The PR enhances parts of the codebase / documentation
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants