Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Proposal for a network programming interface

edited March 2013 in Suggestions Posts: 146

Hi,

starting from a recent question about an ultima online clone in codea, I have been thinking about a way to bring sockets to codea. This is what I came up with:

My proposal is for an interface to sockets, where not every functionality of socket programming is exposed but rather a subset that is good enough for almost all cases. Kinda like what meshes are for 3D programming, you can do almost everything 3D with meshes, but don't get to fiddle with all parts of opengl. Here, you can do almost everything Socket with my proposed interface, but don't get to fiddle with the low level stuff. The reasoning for this is obvious: sockets can not block codea. So everything is non-blocking (except for name server lookups, if that is seen as an issue, it will need a solution).

Apart from the obvious functionality of creating sockets and reading from and writing to them, my proposal revolves around a select function. This is called in draw(), with lists of sockets to check whether they can be read from or written to. Obviously, in codea this function would not block but rather return false if nothing is there to read. To illustrate, here is how this would work (for the sake of this example I call the proposed libraries functions with a socket prefix):

function setup()
  local err
  s, err = socket.connect("someserver", 8000)
  if not s then
    error(err)
    -- fail in some user defined manner
  end
  s:send("Hello I am here")
end

function draw()
  local sockets = socket.select({s})
  if sockets then
    print(sockets[1]:read())
  end
  -- do some other stuff
end

I have a complete implementation of this proposal available to play with on Linux and Mac OS X systems available from http://www.tset.de/lsocket/ (you have to simulate codea's event loop yourself, but if you are able to build the module, that should be a piece of cake ;) ). The only difference between this and the variant I propose to use for codea is that here the select function is actually blocking unless you use a timeout of 0. The timeout argument to select() would of course not be available in codea and would be hard coded to 0. ;) ;)

Tagged:

Comments

  • Posts: 100

    This is very very interesting.
    For a simple approach just reading an udp stream. How would you do that ?
    First the library must be added into Codea, right ? And then your above code.
    Please an example on the process, as this is something I realy could use instead of my selfmade Processing server in between an udp stream and Codea (http.request() )
    Re Peter

  • Posts: 146

    @macflyerdk basically yes, the lib needs to be added to codea, and then like above, just for udp you do something like

    socket.connect("udp", "someserver", 8000)
    

    if you follow the link I posted above, in the archive that contains the library there is also some sample code for servers and clients for tcp, udp and also multi/broadcast, though those are basically for un*xen and thise use blocking select. But it should give you an idea.

    Note that if you add the lib to codea yourself, you should really alter the select function in the c code so that it does not accept a timeout argument and always uses a timeout of zero seconds.

  • BortelsBortels Mod
    Posts: 1,557

    I'd rather see a callback udp-only scheme to match the existing http.request stuff.

    Being able to listen on a socket would open a whole new world.

  • Posts: 146

    You are able to listen to sockets with this. It basically gives you what you want plus more, except you handle the callback stuff yourself (which is one function call). In the example above, replace "print(sockets[1]:read())" with "mycoolcallback(sockets)" and Bob's your uncle.

  • Posts: 100

    I want to try it out :-)
    What exactly do I need to do in Codea / iPad to install the library ?
    I have never messed with these things before, so some help would be appreciated, thanks.

    Guess I can then take it from there using your examples and figure out the best way, but first the library etc...

    Re Peter

  • Posts: 146

    @macflyerdk currently this does not work in codea, it is just a proposal. I don't know if what I implemented will even build or run on the ipad, it is intended for mac or linux. I have no experience with C Obj-C programming on the ipad, I could try to add this to the runtime, but I don't see a lot of time for that in the near future...

  • edited March 2013 Posts: 100

    Ok, fair enough.
    But to bad, I had realy hoped to have udp support in Codea.

    Right now I have a fairly big and allmost finished simulator panel system to work with X-plane.
    Planning on putting it to the AppStore but it is depending on a server running udp and http.request serving.
    My homemade server setup works well but is not something that I can ask an App byer to set up.
    It includes a Processing udp receiver and chruncher, a virtual volume and a Mamp server running.

    So either I go the route and make this in to a standalone server with all build in, or somehow make udp avaivable in Codea.

    Hoping for the later ;-)

    Re Peter

    Edit: Got me thinking that maybe I can use your code for the standalone server in Lua on my Mac. I will give it a try.

Sign In or Register to comment.