Make naming consistent

[vadorovsky]

• Use short names like eth, hdr, proto, since that's what Rust stdlib is doing with network-related names.
• Name the protocol enums after the frames they are included in. So, for example, EthProto for protocol info included in the Ethernet header.
• Remove all from_be methods, callers of the library should do that.
• Use proto enums directly as member field types, so we avoid manual conversion.

Signed-off-by: Michal Rostecki vadorovsky@gmail.com

[dmitris]

$ cargo doc
Documenting network-types v0.0.2 (/Users/dmitris/dev/hack/gh/vadorovsky/network-types)
warning: this URL is not a hyperlink
--> src/l3/ip.rs:94:5
|
94 | /// https://en.wikipedia.org/wiki/List_of_IP_protocol_numbers
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: use an automatic link instead: <https://en.wikipedia.org/wiki/List_of_IP_protocol_numbers>

[vadorovsky]

@dmitris Fixed, thanks for review!

[dave-tucker]

Throwing in some general comments as well here since this is slated for inclusion in the book.
Naming wise, I think I actually prefer the verbosity unless the acronyms are well known - and I mean well known by people outside of networking... 😆

It might also be worth adding to the readme the philosohpy on naming for contributors so they can follow along when adding new protocols.

e.g

1. Prefer field names as described in IEEE, IETF or other standards
2. Where field names contain spaces, replace with _
3. The following contractions are permitted: source -> src, destination -> dst, address -> addr etc...

[vadorovsky]

@dave-tucker

Naming wise, I think I actually prefer the verbosity unless the acronyms are well known

To be honest, I don't have any hard preference whether names should be short or verbose, but Alessandro's point for using the short ones (Ipv4Hdr, eth and so on) is that std::net is using shortened names and almost never fully verbose ones.

[dmitris]

Re src/dst vs. src_addr/dst_addr, I think the most logical and easiest to remember would be the name that is closest to the ones used in the related Linux kernel structures. If have to choose between short and verbose, my preference would be on the short/succinct side.