Network API

[worktycho]

No, it just parses HTTP. However we could modify cHTTPServer to just be a wrapper around libevents server. libevents server does support HTTP 1.1 including chunked encoding and multiple requests per connection.

[xoft]

Maybe so, but I'm worried about those unlimited transfers. What if someone tries to upload a gigabyte file? I'd be careful for the beginning and just change the IO part of the http server; we can change it later on.

I've committed the basic libevent inclusion setup to github, we'll see if it compiles on linux; it does compile in msvc as it is now.

[jan64]

Also, it would be nice to include a function to list all links connected to the server. (although, that's not really critical - plugin developers can do this themselves)

[worktycho]

I'm interested in what information you think the API would give over what is available through the standard external tools like netstat?

[jan64]

I was talking more about in-plugin use (broadcasting something to all connected clients).

[worktycho]

That would be at the cServer level. Your talking about some exposure of a list of clients. MCServer can accept incoming network connections in at least two other ways at the moment (HTTP and RCON), and generate outgoing HTTP requests. And if the net API is exposed to plugins it will generate more. This change is to the abstraction layer over the OS networking APIs at which point we are talking about raw data.

Also if you want to send something to all connected clients you use cRoot():Get():ForEachPlayer(), or one of the cRoot():Get():BroadcastChat Family. The API you are asking for doesn't exist because there is no guarantee that the list will still be valid when you use it due to multi-threading.

[jan64]

No. What i'm talking about is a method available through ServerHandle, which would give you links to all connected clients. (list of all clients of the echo server, which listens on non-mc port, for example)
Also, ondisconnect callback could be usefull. (for both server and client, and the onSuccess callback could be renamed to onConnected)
+ The listen function should have callbacks for onerror too, imo.

[worktycho]

What would you use it for other than a poor substitute for proper server monitoring tools? It would have to be useful as implementing it would impose a chokepoint on server connections.

[jan64]

I'm talking about the list of clients connected to your server created using Network:Listen(). This can be actually useful for custom protocol broadcast purposes (like implementing irc server using lua).

[worktycho]

I think I see. With a list per listening socket. It might be worth implementing.