Cuberite Forum
Network API - Printable Version

+- Cuberite Forum (https://forum.cuberite.org)
+-- Forum: Cuberite (https://forum.cuberite.org/forum-4.html)
+--- Forum: Development (https://forum.cuberite.org/forum-13.html)
+--- Thread: Network API (/thread-1700.html)

Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15


RE: Network API - wolfmitchell - 01-05-2015

(01-05-2015, 01:59 AM)jan64 Wrote: This looks great, finally there will be a way to implement irc bridge! Smile

I did already using LuaSocket. Works quite nicely, just set the timeout to 0.01 and check to make sure you got data before trying to use it :p


RE: Network API - jan64 - 01-05-2015

That's a hacky way to do it. I'm talking about either coding one using asynchronous luasockets, or waiting for the asynchronous api.Tongue


RE: Network API - xoft - 01-05-2015

I'm thinking about basing this all on the libevent project: http://libevent.org/


RE: Network API - wolfmitchell - 01-05-2015

(01-05-2015, 07:22 AM)jan64 Wrote: That's a hacky way to do it. I'm talking about either coding one using asynchronous luasockets, or waiting for the asynchronous api.Tongue

but hey, it works! It'll do until the network API is created and everything.


RE: Network API - worktycho - 01-05-2015

If we do use libevent, we should used the "bufferevents" API rather than the event loop, because it also supports windows IOCP.


RE: Network API - xoft - 01-06-2015

bufferevents are used within the event loop.


RE: Network API - worktycho - 01-06-2015

I know, I meant using the abstraction rather than the raw network events directly.


RE: Network API - worktycho - 01-06-2015

If we use libevent, will we replace the the http server with libevents implementation?


RE: Network API - xoft - 01-06-2015

It is rather undocumented, so I don't know yet. Do they have a proper parser for things like form data?


RE: Network API - xoft - 01-06-2015

Also, evhttp seems to read the entire request into memory before calling the callback; this would allow malicious clients to crash the server by sending an arbitrarily-long request. Our parser is better in this way, it parses stuff as it comes and calls callbacks, discarding data when it's been processed. I'd say we keep our http parser for the time being.