futile / enet-rs

High-level bindings for the ENet networking library (http://enet.bespin.org)

High-Level, Rust-y Bindings for the ENet library

This crate aims to provide high-level, rust-y bindings for the ENet library. ENet is a networking library for games that builds on UDP, offering optional reliability, congestion control, connection-orientation and other related features. For more information, check out the ENet Website.

Status

For now, this library is alpha. It builds on the C-bindings for ENet, the enet-sys crate. A lot of the functionality is there, but not everything. Also, since ENet has pretty unclear lifetime semantics, you might actually run into cases where things crash. In those cases, or when something is missing/not yet in the API, open a bug report, and I will look into it as soon as possible.

Usage

To check what the latest released version is, check on https://crates.io/crates/enet, or use cargo add from cargo edit to automatically add a dependency to the most recent version.

Installation is as simple as adding this to your Cargo.toml:

[dependencies]
enet = "0.3.0"

Documentation & Examples

Documentation is available on https://docs.rs/enet or by running cargo doc. An example server and client can be found in the examples directory.

License

Licensed under either of

• Apache License, Version 2.0 (LICENSE-APACHE or http://www.apache.org/licenses/LICENSE-2.0)
• MIT license (LICENSE-MIT or http://opensource.org/licenses/MIT)

at your option.

Contribution

Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.

enet-rs's Issues

Find out what maximum for max_peers is

When calling Enet::create_host, the max_peers argument sets the maximum peer count. However, the type of this argument is usize, but probably less than usize::MAX peers are supported. Finding out the maximum count most likely needs to be done by looking into the ENet docs + source. It can then be turned into a specific enum like ChannelLimit etc.

error

everything is from this repo
just changed the port and made it UNSPECIFIED instead of localhost

Clear all peer data when ENet is shut down

Currently, when ENet is shut down (e.g., because the application exits), we don't clean up data associated with peers (as this only happens when an Event::Disconnect is handled).

error in enet

Hello i was trying to connect to it to make sure its working but it wasnt print new connect! or disconnect! and it doesn't print error msgs as well so i tried to make this
loop {
println!("{:?}", host.service(1000).unwrap())
}
to see what is actually gives
so it was showing this

so i dont know where is the error exactly and im using the example of server

multithreading?

for this solution is multithreading possible with tokio for example?

RUSTSEC-2022-0013: Regexes with large repetitions on empty sub-expressions take a very long time to parse

Regexes with large repetitions on empty sub-expressions take a very long time to parse

Details
Package	regex
Version	0.2.11
URL	https://groups.google.com/g/rustlang-security-announcements/c/NcNNL1Jq7Yw
Date	2022-03-08
Patched versions	>=1.5.5

The Rust Security Response WG was notified that the regex crate did not
properly limit the complexity of the regular expressions (regex) it parses. An
attacker could use this security issue to perform a denial of service, by
sending a specially crafted regex to a service accepting untrusted regexes. No
known vulnerability is present when parsing untrusted input with trusted
regexes.

This issue has been assigned CVE-2022-24713. The severity of this vulnerability
is "high" when the regex crate is used to parse untrusted regexes. Other uses
of the regex crate are not affected by this vulnerability.

Overview

The regex crate features built-in mitigations to prevent denial of service
attacks caused by untrusted regexes, or untrusted input matched by trusted
regexes. Those (tunable) mitigations already provide sane defaults to prevent
attacks. This guarantee is documented and it's considered part of the crate's
API.

Unfortunately a bug was discovered in the mitigations designed to prevent
untrusted regexes to take an arbitrary amount of time during parsing, and it's
possible to craft regexes that bypass such mitigations. This makes it possible
to perform denial of service attacks by sending specially crafted regexes to
services accepting user-controlled, untrusted regexes.

Affected versions

All versions of the regex crate before or equal to 1.5.4 are affected by this
issue. The fix is include starting from regex 1.5.5.

Mitigations

We recommend everyone accepting user-controlled regexes to upgrade immediately
to the latest version of the regex crate.

Unfortunately there is no fixed set of problematic regexes, as there are
practically infinite regexes that could be crafted to exploit this
vulnerability. Because of this, we do not recommend denying known problematic
regexes.

Acknowledgements

We want to thank Addison Crump for responsibly disclosing this to us according
to the Rust security policy, and for helping review the fix.

We also want to thank Andrew Gallant for developing the fix, and Pietro Albini
for coordinating the disclosure and writing this advisory.

See advisory page for additional details.

Socks5 support

Does this support socks5?

RUSTSEC-2022-0006: Data race in `Iter` and `IterMut`

Data race in Iter and IterMut

Details
Package	thread_local
Version	0.3.6
URL	Amanieu/thread_local-rs#33
Date	2022-01-23
Patched versions	>=1.1.4

In the affected version of this crate, {Iter, IterMut}::next used a weaker memory ordering when loading values than what was required, exposing a potential data race
when iterating over a ThreadLocal's values.

Crates using Iter::next, or IterMut::next are affected by this issue.

See advisory page for additional details.

Host::peers not working as intended + question about storing peers

Hello there!

I've started using using this library because I was working on a game with some friends, the project was discontinued, but I still fiddle with the library, trying to get something working, and I like it so far!

That said, as I haven't used this library before, I ran into some issues.

I have Client and Server structs:

struct Client {
    host: enet::Host,
    server: enet::Peer<()>,
}

struct Server {
   host: enet::Host,
   clients: Vec<enet::Peer<()>,
}

As you can see, I want to store the peers so that I can send stuff to them. Now, I'm aware that the documentation says:

The lifetime of these instances is not really clear from the ENet documentation. Therefore, Peers are always borrowed, and can not really be stored anywhere.

And indeed I've tried to add lifetimes to my structs, but to no avail.

Then, I noticed method Host::peers() and thought that I don't really have to store the peers if Host stores connected peers for me. But whether I connect my client to the server or not, peers() always returns an iterator over 10 peers (so maximum numbers of peers i provided in a constuctor, as I'm using code from the examples, just with these structs above).

So, what's the correct method to use the library in bigger projects that involve structs? Because I reckon you have to store the peers somehow.

`enet::Address` byte order issue when read from `enet::Peer`

Hey there! Thank for this cool library.

I’ve come across a small issue while using it. It appears that if an enet::Address is read (back) from the ENet library, the byte order ends up wrong, at least on my ordinary LE system. Meanwhile, if I manually construct an enet::Address via ::new, it has the 'right' byte order.

Meaning, if I call Address::new(Ipv4Addr::LOCALHOST, 5000).ip().to_string() then I get 127.0.0.1;
but for a given peer.address().ip().to_string() I would get 1.0.0.127.

Would be great if you could fix this!
Cheers

ENet appears to actually support reliable unsequenced packets

enet-rs/src/packet.rs

Line 17 in c62e299

/// ENet does not support reliable but unsequenced packets.

See this:

lsalzman/enet#255 (comment)
lsalzman/enet@29260f7

ability to check peer.ConnectId

Is there a way to get the ConnectId of the peer? if no i suggest that as a new feature.