Dependency Injection Recommendations

[blankfunc]

As a lightweight data layer transport protocol, ENET should not be limited to the underlying udp. I think that limits its use.

In network environments such as p2p and even tcp networks, enet is useful, perhaps a transport layer protocol that does not belong to QUIC in most respects.

Therefore, I think the network layer of enet should not be bound to udp, but should be abstracted into data exchange operations such as send, recv or config in the form of dependency injection.

[JG-Adams]

Can you clarify what you mean by abstracting the transport layer? ENet is designed around UDP’s characteristics—low latency, unordered delivery, and selective retransmission. Replacing UDP with TCP would remove ENet’s key advantages, such as avoiding head-of-line blocking with multiple channels. If your concern is P2P or NAT traversal, libraries like STUN already handle that within UDP. What specific problem do you think this would solve?

[blankfunc]

This is a library written by c, but the application area definitely does not end with c.

I encountered development problems when binding enet with ffi in rust.

If i only use udp, enet is a pretty handy and compact library. But when I want to use enet on the udp opened by p2p, the binding of enet and socket hinders my implementation.

And I don't want to use quic. On the one hand, it was too unwieldy for my project, on the one hand, quic's packet characteristics and traffic consumption make it easier to block my network (restrictions from chinese operators).

That's my main problem.

What I hope is that enet can open up the underlying interface for developers to interface with their own network interfaces, not that enet can add support for tcp.

[blankfunc]

Can you clarify what you mean by abstracting the transport layer? ENet is designed around UDP’s characteristics—low latency, unordered delivery, and selective retransmission. Replacing UDP with TCP would remove ENet’s key advantages, such as avoiding head-of-line blocking with multiple channels. If your concern is P2P or NAT traversal, libraries like STUN already handle that within UDP. What specific problem do you think this would solve?

Oh, I'm sorry I may not have made myself clear.

I mean, open up enet's "incoming data" and "outgoing data" (and maybe "configuration"), instead of using socket directly within the project. Just like quiche doing, this may increase applicability.

[JG-Adams]

Oh, so use the ENet's reliability, fragmentation assembly, ect... But work with external socket instead of strictly using ENet's UDP connection. That sound like a good feature to have as part of core.

I could see one interesting way to do it. Let's evaluate.

This ENet requires you to have a peer in order to send data:
enet_peer_send(peer, channelID, packet);

You get the peer from the event:
enet_host_service(host, &event, timeout)

You get your host from: enet_host_connect(host, &address, NET_CHANNEL_COUNT+1, 0);
Which creates the socket and store the socket in host. The host has pretty much all the configuration.

So you see, socket is mixed in all the code that make ENet useful. That would require some major overhaul.

I suppose that if you add another parameter to the enet_host_connect function, a pointer to external socket. If it's NULL it will generate the socket and simply use all the internal features as normal. Otherwise use existing socket and everything else should work?
enet_host_connect(host, &address, NET_CHANNEL_COUNT, 0, &externalUDPSocket);
host will track whether it use its own socket so we don't close socket when destroying the host.

I will make a branch for you to test your program in.

[JG-Adams]

I'll need your help to test this. Place your socket in the new parameter of enet_host_connect().
https://github.com/JG-Adams/enet

This is a start. We can try to replace the need for peer. (But there isn't really a point to do so. I believe ENet already support P2P as you earlier seems to describe wanting to use? This function here might help you really customize your data sending, enet_host_send_raw(ENetHost host, const ENetAddress address, enet_uint8* data, size_t dataLength); But it doesn't have the same implementation as the regular peer send.)
I'm honestly not entirely sure if this is the best way to go about it. But you really can't just send and receive data without the socket so. I think this is pretty good for your need.

NOTE: I also put in is_udp_socket() which is to check whether the provided socket is UDP or not. ENet only support UDP afterall. I am not certain at all if this would work even as it has cross-platform implementation. So I need help on that.

Things to Test:
Successful use of external socket.
enet_host_destroy() should be called before destroying your own. (It should not close it itself.)
is_udp_socket() should be valid.

[mman]

@JG-Adams @metafunc For anybody interested: my fork here: https://github.com/mman/enet contains a full implementation of BIO - basic input output where you can essentially plug in your own routines to replace networking calls. I have used it to create an implementation of ENet on top of Apple's Network.framework nicely.

https://github.com/mman/enet/blob/bfe35f6c1f852c64177d985b4b3735044685c273/include/enet/enet.h#L352-L365

[blankfunc]

Wow! Thank you for your positive response and support! (I'm sorry to say that I'm going through the college entrance examination, so I may not be able to develop it for a short time 😢)

[JG-Adams]

@metafunc That's all right. Take your time and come back soon! :) @mman Thanks for the reference. I might not have the time or energy to go through all the codes but it look like you use another struct called BIO that contains similar stuff that host would. My solution here is to directly use the external socket and take the pointer into the host's socket. which can then be configured in any way along with ENet configuration. Perhaps you can review my codes and see what you think? I only added a few things here and there.

[zpl-zak]

I kinda get the issue here, once I've stumbled upon a similar situation whilst working on a project that eventually got ported to Emscripten. Luckily the application used enet as a plug and play library, so an alternative could have been used quite easily. For projects that heavily rely on enet however, I can totally understand the need for having the internal driver/sockets logic swappable and customisable.

If anyone is willing to work on such a feature, it would help immensely, I am totally on board with the idea. Thank you @mman for providing a reference and @JG-Adams for looking into this topic!

[sacrificerXY]

If I'm understanding this thread correctly, does this mean you can even use ENet outside of a networking context?

I'm imagining a use case where you want to test some protocol. So you have this test program where you spawn a server and client/s and instead of giving ENet live sockets, you have simulated sockets. ENet will just keep working not knowing that the network it's experiencing is actually artificial/simulated.

Though I guess you also have to expose the timing functions for dependency injection. You can then run tests/simulations faster than realtime.

[JG-Adams]

@sacrificerXY Sounds like you're referring to loopback? You can already do that actually. (0.0.0.0 or 127,0,0,1) I think what we're trying to do here is make it possible to use external socket instead of just ENet internal socket and to be able to benefit all its best features. What you do with it I'm not entirely sure. Except maybe you can implement a certain protocol with it to probably tighten security, perhaps share the same port, Supposedly if the project uses multiple network protocols (e.g., WebRTC, VoIP, or raw UDP traffic), an external socket can manage all communication efficiently.

I don't know that much about all of it. But that's my guess.

But if you ask me. ENet is great on its own for making games. It wouldn't hurt to support external sockets if it could be simple. #73 is pending for reviews.

[blankfunc]

I was admitted to a decent university🙂, and now I am coming back to try to implement the issue:

Re-Enet

At present, I have deleted all internal SOCK bindings and written a set of UDP underlying encapsulation for my proposed Transport abstract encapsulation input. I am currently trying to make modifications and connect the official ENET server.

However, there are currently some issues. I have written data monitoring on UDP docking, and after comparing with the official ENET, I found that the data is consistent. However, I am still unable to connect server and am currently investigating the problem :)

[JG-Adams]

I wonder what this is for?