Networking API RFC (enet?)

[fysx]

Hi everyone,

I am currently thinking of a way to improve Löve's networking capabilities and propose an API for it. Any comments or suggestions would be welcome. Also whether there is an actual interest in such an API in Löve could encourage me to actually complete my current implementation.

Currently in Löve there is support for raw tcp or udp sockets, which combined with bartbes' LUBE is quite usable but it still mostly is raw tcp and udp.

On the other hand there is e-net, which is a nice light-weight networking library that is based on udp but also lets you do the things that tcp provides, but on a per-packet basis. For e-net there is also a nice lua wrapper for its api available (thanks to Leafo).

While LUBE has a nicer and more concise API (in my opinion) it suffers from some features that e-net provides (i.e. reliable / unreliable packets, keeping track of pings, channels over the same connection). However the API of e-net is rather general and not entirely intuitive.

All the approaches are okay, but in my opinion something simpler would be nice to have in Löve. I would therfore propose an extension to Löve which is based on e-net, which exposes a simpler and more concise API to networking, that should simplify making networked games.

Code: Select all

    -- Server
    server = net.newServerSocket(
        address, connect_callback, receive_callback, disconnect_callback,
        [max_client_count = 16, channel_count = 8,
        incoming_bandwidth, outgoing_bandwidth])

    server_connect_callback (client_info) 
    server_receive_callback (client_info, channel, data)
    server_disconnect_callback (client_info)

    server:service([timeout]) -- processes all packets and
                              -- executes  callbacks
    
    server:getClientInfo (client_info.id)
    server:getPing (client_info.id)
    server:send (client_info.id, data, [channel = 1], [flags = reliable])
    server:sendAll (data, [channel = 1], [flags = reliable])
    server:disconnect (client_info.id)
   
    -- Client
    client = net.newClientSocket(
      connect_callback, receive_callback, disconnect_callback,
      [channel_count = 8, incoming_bandwidth, outgoing_bandwidth]
    )

    client:connect (address)
    client_connect_callback (server_info)
    client_receive_callback (channel, data)
    client_disconnect_callback (server_info)

    client:send (data, [channel = 1], [flags = reliable])
    client:getPing ()
    client:disconnect()

The tables client_info and serve_info represent the peer structs of e-net and can be used to query for the actual ip and port of the connections. In general however, only their ids are used during a connection.

Comments? Interest?

[Boolsheet]

I think ENet would fit many use cases in LÖVE and it surely would be a enhancement. However, I never used ENet and can't comment on API specifics. I would like to point out that callbacks from C to Lua are a bit of a pain and it may be better to aim for a pull-style API with the connect, disconnect and receive events.

Also, pedantic mode on: I think the proper spelling is ENet. Capital 'E'. Capital 'N'. No dash.

[bartbes]

For now, I'd be more interested in adding lua-enet, in the way luasocket is, since that does get us the enet awesomeness, but not the maintenance costs.
Additionally, I, personally, would probably add an enet module to LUBE once it is in (since the new LUBE is meant to be modular you could even do it yourself, or write your own udp+).

[fysx]

@Boolsheet: to me using callbacks is both more convenient to use and also worth the effort to implement on the C side. Pulling for ENet events adds boring code that one has to looked-up everytime you want to get started. (Oh... and thanks for the -pedantic warnings!)

@bartbes: integrating leafo's ENet wrapper and wrapping it again in LUBE to make it accessible is okay. But why not create a usable networking API right away? I do see the point about the maintenance costs, however I am not sure whether it makes sense to wrap udp, tcp and ENet as the latter introduces quite a few concepts that would have to be implemented for udp and tcp to have it consistent.

On the other hand, exposing nearly full ENet API to Lua and then create a nicer API in Lua does seem worthwile to me now.

[slime]

An official LÖVE ENet API will satisfy me under 2 conditions: it should be as consistent as possible with the rest of the LÖVE API, and it should provide access to as much of what pure ENet can do as possible without sacrificing the cleanliness of the API too much.
I didn't use lua-enet a ton, but IIRC it mostly mirrors the official ENet API, and I found it fairly intuitive to use - the event polling loop is nothing new to someone who has looked at love.run before, so I don't see the need to replace it with something completely different.

Small networking test programs used to determine what is necessary to expose and what is not may miss crucial features that a larger program absolutely needs, or they may mislead the programmer into thinking a particular API choice is a good one when in fact it makes it more cumbersome and less intuitive for those who want to make more in-depth programs.

[fysx]

It makes now more and more sense to me to expose ENet's API to the developer and I'll continue in that direction.

To be close to Love's API would mean to use CamelCase instead of separation_by_underscores, right? Currently the latter is used in Leafo's wrapper.

*edit* (accidentally clicked on submit):
So I would change it to CamelCase. I'll review the code I have so far and add ENet functions that are missing in the wrapper and also add accessors to member variables that could be useful.

[kanadezwo]

https://bitbucket.org/MartinFelis/love-enet could be interesting.

[bartbes]

I'm pretty sure that is fysx' fork .

[fysx]

Yep, I am *quite* familiar with that fork .

[kanadezwo]

Uhm ... okay.

Thanks for the information.