[ENet-discuss] ENet 2.0 most wanted features?

[James Bellinger]

My list is less exciting than most, but here goes.

(1) A 'get ENet version' function. Linux distributions tend to lag on 
versioning, and this would allow precompiled binaries to take advantage 
of new features if a new version is detected, without breaking 
compatibility (newest Ubuntu is still on 1.3.3 for instance).

(2) Consistent library naming. libenet.so symlinks tend to be in 
developer packages, so that can't be used directly, and I noticed on 
Ubuntu it's libenet.so.1 while the Git repo builds libenet.so.2. This 
could be a problem for distributing precompiled binaries.

(3) C accessors for parts of structures that are meant to be accessed, 
so that ENet structures can be treated as opaque. Seems to be a pattern, 
all of these three have been related to binary compatibility. :)

(4) EINTR. When we discussed this I was coming from the angle of using 
Mono, which provides no useful access to signals, so I didn't understand 
your meaning. Pondering other platforms where signals could be useful I 
see your point. That said, lack of EINTR handling does need some 
resolution - at the very least, some way to know ENet is returning a 
failure case that should just retried.

Biggest problem if one goes that route is enet_host_service being a 
timeout not a time. Maybe if the timeout parameter in a 
enet_host_service2 were a pointer type and was decremented by elapsed 
time? That'd do the trick and be compatible with the way you were 
talking about..

(5) ENetBuffer's structure is in reversed order Unix vs. Windows. Opaque 
structures would solve this, but might be overkill for such a simple 
one. Unless there is a technical reason for this difference, it'd be 
nice if it could be unified.

(6) Could ENetSocket be made always of uintptr_t size? This difference 
means I cannot practically expose the low level socket APIs in a 
cross-platform manner.

(6) Is thread-safe reference count increment/decrement architecturally 
practical? On Mono one cannot control the thread for cleanup. The 
practical effect is that ENet structures on Mono have to be disposed of 
manually and can't be made to work with automatic garbage collection. 
This is really not critical, but *if* it's not overly complicated ENet 
could be made downright pleasant to work with from C#.

(7) The 'simulate lag/packet loss' that I see many posts of would be 
nice. For simulating lag, perhaps you could use the outgoing queue's 
retry timing but just also apply it before the first packet is sent?

If I can be of help on any of these please let me know.

Have a good day

James

On 4/30/2013 5:43 AM, Lee Salzman wrote:
> So, I'm just thinking in the back of my mind what sort of things would 
> be desired in a hypothetical version 2.0 of ENet that broke API 
> compatibility and so could do things that would otherwise not be 
> possible in a 1.x release.
>
> That doesn't mean that a 2.0 is in the near future, but I'd like to 
> get a dialogue going about it.
>
> Aside from IPv6 support, are there any other big things people would 
> want that are none-the-less realistic and not overly complicated?
>
>
> _______________________________________________
> ENet-discuss mailing list
> ENet-discuss at cubik.org
> http://lists.cubik.org/mailman/listinfo/enet-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cubik.org/pipermail/enet-discuss/attachments/20130430/21374773/attachment.html>