You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A UDP-based protocol that provides partial reliability. Coming soon!
18
+
This library implements some TCP-like features on top of an UDP-socket.
19
+
It will provide a lightweight message-based interface with certain guarantees like reliability, fragmentation congestion monitoring.
19
20
20
-
## Note
21
+
Laminar was designed to be used in the [Amethyst][amethyst] game engine and is loosely based on articles from [gaffer on games](https://gafferongames.com/).
21
22
22
-
This library is not yet stable. It is experimental and things may change frequently.
// Start receiving (blocks the current thread), use `udp_socket.set_nonblocking()` for not blocking the current thread.
97
109
letresult=udp_socket.recv();
98
110
99
111
matchresult {
@@ -124,6 +136,12 @@ match result {
124
136
125
137
We want to give credit to [gaffer on games](https://gafferongames.com/) as we have used his guide to building a game networking protocol to build this library.
126
138
139
+
## Note
140
+
141
+
This library is not fully stable yet.
142
+
Although version 0.1.0 is released we might have to change some of the existing API.
143
+
Laminar is used in [Amethyst-Network](https://github.com/amethyst/amethyst/tree/master/amethyst_network), you could give that a look if you want to see some more advanced use-cases.
144
+
127
145
## Contribution
128
146
129
147
Unless you explicitly state otherwise, any contribution intentionally submitted
As a team, we adopted the following the workflow agreements. When we begin work on the amethyst_network crate, we’ll use the same agreements. They are focused on maintaining a high level of quality in the code, and for working with a highly distributed team. We’re including them here as some of the other teams may find them of use.
4
+
5
+
- All warnings produced by `cargo test` are treated as errors by the CI/CD system
6
+
- All `clippy` warnings are treated as errors by the CI/CD system
7
+
- We use `kcov` to track our code coverage; we do not have a required minimum, rather we use this as a potential indicator of issues
8
+
- We included sample code about using the library
9
+
- Setting up a benchmarking framework so we can track regressions
10
+
- Unit and integration tests, as well as release testing with docker-compose
11
+
12
+
## Style Guidelines
13
+
14
+
As a team, we (eventually) agreed on a coherent style for all our work. See this [document](https://github.com/amethyst/laminar/blob/master/docs/CONTRIBUTING.md#code-style) for more information.
15
+
Some of the most helpful ones have been:
16
+
17
+
- Keep PRs small, preferably under 200 lines of code when possible
18
+
- Comments should explain why, not what
19
+
- You must provide comments for public API
20
+
- No hard-coded values
21
+
- No panics nor unwraps in non-test code
22
+
-`rustfmt` stable release must be used
23
+
-`rustfmt` should be done as its own PR, to avoid generating giant PRs that are impossible to review
24
+
- We make use of the [forking workflow](https://nl.atlassian.com/git/tutorials/comparing-workflows/forking-workflow)
25
+
26
+
## Code style
27
+
28
+
Some code guidelines to keep in mind when contributing to laminar or amethyst-networking
29
+
1. Comments
30
+
- Comment all code you’ve added. Things you should comment: types, methods/functions public fields of structs.
31
+
- Calculations should be documented. Whether it would be in a PR or code. But it must be clear what is done.
32
+
- Public things should get docstring comments using `///`. Non-public things may use `//` comments
33
+
- Keep comments small
34
+
- Don’t create unnecessary comments. They must add value
35
+
- Comments should explain the “why” not the “what”
36
+
2. Hard Coding
37
+
- Don't hard code values anywhere
38
+
- Use the ‘NetworkConfig’ type for common network settings, use consts or parameter input
39
+
- Use of lazy_static is acceptable but first make sure you can’t fix the issue in other ways
40
+
3. Code markup
41
+
- Keep files small. Better have small files with small pieces of logic than having one file with 1000 lines of logic with multiple types/structs etc. Note that I speak of logic, tests not included
42
+
- No panics/unwraps in the main codebase, but they are accepted in tests
0 commit comments