104 replies to this topic

[Lyqyd]

minizbot2012, on 17 July 2012 - 08:45 PM, said:

The example client / server pair is out of date. Is it possible that you can provide updated example client / servers?

Absolutely. I'll see about updating those tonight. They aren't too badly out of date, but the documentation needs updating due to the sockets model taking the place of named servers.

[minizbot2012]

Lyqyd, on 17 July 2012 - 08:47 PM, said:

minizbot2012, on 17 July 2012 - 08:45 PM, said:

The example client / server pair is out of date. Is it possible that you can provide updated example client / servers?

Absolutely. I'll see about updating those tonight. They aren't too badly out of date, but the documentation needs updating due to the sockets model taking the place of named servers.

wow quick response and thank you.

[Lyqyd]

minizbot2012, on 17 July 2012 - 08:48 PM, said:

Lyqyd, on 17 July 2012 - 08:47 PM, said:

minizbot2012, on 17 July 2012 - 08:45 PM, said:

The example client / server pair is out of date. Is it possible that you can provide updated example client / servers?

Absolutely. I'll see about updating those tonight. They aren't too badly out of date, but the documentation needs updating due to the sockets model taking the place of named servers.

wow quick response and thank you.

The README has been updated with correct documentation and corrected background/foreground server and client example programs.

[minizbot2012]

Lyqyd, on 18 July 2012 - 03:42 AM, said:

minizbot2012, on 17 July 2012 - 08:48 PM, said:

Lyqyd, on 17 July 2012 - 08:47 PM, said:

minizbot2012, on 17 July 2012 - 08:45 PM, said:

The example client / server pair is out of date. Is it possible that you can provide updated example client / servers?

Absolutely. I'll see about updating those tonight. They aren't too badly out of date, but the documentation needs updating due to the sockets model taking the place of named servers.

wow quick response and thank you.

The README has been updated with correct documentation and corrected background/foreground server and client example programs.

thank you very much.

[gmt2001]

This is a very nice API and i am happy to finally see an "Internet" api which does not appear to be a cheap routing interface but rather a fully thought out api with all of the required things to make simulation of routing, TCP, and UDP possible which are all important if we wish to properly make the kind of client/server programs that everyone claims they are making.

[minizbot2012]

i have built a prototype of a client file storage API, using this: http://www.computerc...ersistence-api/ persistence api, it is currently under heavy development using this system. Got variable retrieval working. />

Lyqyd if you want the source i will happily provide it

[Lyqyd]

minizbot2012, on 19 July 2012 - 09:55 PM, said:

i have built a prototype of a client file storage API, using this: http://www.computerc...ersistence-api/ persistence api, it is currently under heavy development using this system. Got variable retrieval working. />

Lyqyd if you want the source i will happily provide it

I'm a bit confused as to what you mean. Are you talking about making a LyqydNet-based file server?

[minizbot2012]

Well I am not making a file server persay, but a way to store variables on the client, via a type of scripting language that can be sent through rednet without having to use loadstring(). Also it is sandboxed to a small area on the computer.
EDIT: encryption system did not work out />

[vipes2010]

This is a very cool networking API. I have been playing around with it as I'm working on a complex nuclear reactor control system with multiple computers controlling the reactor, cooling storage, uranium storage, and spent fuel storage pool.

Only thing I'm wondering about is if this can work over bundled cables... I can only get it to communicate over wireless modems.

[Lyqyd]

vipes2010, on 29 August 2012 - 03:10 AM, said:

This is a very cool networking API. I have been playing around with it as I'm working on a complex nuclear reactor control system with multiple computers controlling the reactor, cooling storage, uranium storage, and spent fuel storage pool.

Only thing I'm wondering about is if this can work over bundled cables... I can only get it to communicate over wireless modems.

I don't see any reason why it couldn't be used for networking on bundled cables. You would probably need to open the side you wanted to use for networking manually, though. When I get home from work, I'll check the initialization function to see whether the lack of a wireless modem will keep initialization from happening properly. If it does, I'll add an argument to force usage of a specific side for networking, I think.

[Lyqyd]

Okay, I think this should work:

Download this version of the net API file, placing it where appropriate. Call the initialization function with a side argument, for whichever side you want to use for networking, thus:

net.netInit("back")

Bear in mind that networking over bundled cables is significantly slower (since the data is actually being transmitted in real time through rednet pulses, rather than being magicked from computer to computer), so certain protocols may be unpleasant to use, such as the terminal redirection over rednet. If you've got a fairly low network usage application in mind, you may not notice too much of a problem with latency.

[Wolvan]

Am I allowed to add this to my rednet API by giving full credit?

[Lyqyd]

Wolvan, on 01 September 2012 - 11:07 AM, said:

Am I allowed to add this to my rednet API by giving full credit?

You are free to use portions of LyqydNet as inspiration, such as the terminal redirection over rednet or the magic directory functionality. Credit for these sorts of things is appreciated, but I'm pretty laissez-faire about that.

However, it doesn't make much sense to me for others to include LyqydNet in its totality as a part of another API. It would make much more sense if you were to require the LyqydNet API as a dependency, and then build on top of the work I've already done. LyqydNet is intended to operate as an intermediary layer to assist in simpler point-to-point communications via rednet. Additional modified versions of LyqydNet could create confusion and incompatibilities, which is something that I think is best to avoid.

If I may ask (and feel free to respond via PM instead), what is it about LyqydNet that you'd like to include? Having more information may allow me to answer your question more easily. Thanks for the interest!

[robhol]

Downloaded this yesterday and dropped the files in place. Unfortunately, I really can't get it to work.

I tried setting up a small network at my base, consisting of two computers and a router. Startup scripts are what they should be, modread netd (routed), and I tried netmon start at the router.
Basically, I tried both server versions from the README, and I can connect using the open command. As soon as I write anything else, both the server and client "lock up".

I tried rolling my own simple program, but was never able to connect to the server at all.


Are the docs and/or example programs out of date? Common issues? How do I fix it?

[Lyqyd]

The master branch is a bit out of date, pending documentation updates in the development branch. I do need to re-write the documentation for the example server and client, which I'll try to get to this weekend. In the meantime, the development branch of LyqydNet should be more fully-functional, though the documentation is still lacking. The example client and server in that branch don't look incorrect at a glance. This weekend, I'll be sure to vet those and push a fully-working and fully-documented version to the master branch. I'm sorry about the trouble you've had getting it up and running. One thing you might try (after installing the development branch) is seeing if you can get a net shell session up and running (client and server). Just run nshd (the server) on one computer, and use 'net shell <serverlabel>' on the other. If that can get up and running, the problems are with the example client/server, which means I really need to get it up to date.

Thanks for the interest!

Edit: Had a few minutes. Corrected example server (for use with the development branch of LyqydNet only):

local connections = {}

while true do
    --wait for input from client connections on socket 21.
    conn, messType, message = connection.listen(21)
    --okay, we have a packet, see if the connection is one we already
    --know about.
    if connections[conn] and connections[conn].status == "open" then
        --we can use additional entries in our 'connections' table
        --(which is internal to the server app) to store information
        --about client state, among other things.
        if messType == "data" then
            --handle client input here; use the connection number in
            --'conn' to send data back.
            print(message)
            connection.send(conn, "done", "OK")
            --break packet tells the client we are done transmitting
            --and are ready for the next command. This is optional. Some
            --types of servers wouldn't need to use this, e.g. a chat
            --server.
        elseif messType == "close" then
            --client has closed the connection, so let's close out
            --the connection information.
            connection.close(conn, disconnect, true)
            connections[conn].status = "closed"
            connections[conn].name = nil
        elseif messType == "instruction" then
            --these are local instructions. Often unused.
            if message == "stop" then
                return true
            end
        end
    elseif messType == "query" then
        --a client wants to open a connection
        if connections[conn] then
            --already have an entry for that connection number,
            --reset the information
            connections[conn].status = open
            connections[conn].name = connection.name(conn)
        else
            --no entry for this connection number, set up a new
            --entry.
            local connect = {}
            connect.status = "open"
            connect.name = connection.name(conn)
            table.insert(connections, conn, connect)
        end
        --either way we set up the connection, let the client know
        --it was successful.
        connection.send(conn, "response", "ok")
    end
end

The problem was that the server was sending back the wrong packet type after receiving a text response, so the client (waiting for a different packet) never saw the correct one arrive and just kept waiting. That's fixed in this example server, and I'll push the update to the documentation.

[Namarius]

It seems like that turtles aren't good routers. Is that correct? Because I have massive problems with setting up an always online network with turtle satellites.

[Lyqyd]

Namarius, on 11 October 2012 - 10:45 AM, said:

It seems like that turtles aren't good routers. Is that correct? Because I have massive problems with setting up an always online network with turtle satellites.

Well, routers are supposed to be stationary, so of they're moving around, computers will have a very difficult time maintaining connections. It's also possible that the turtle is overriding the computer-type code to show up as a turtle instead of a router. I'll take a look through the code tonight. In the meantime, your best bet is probably to use a turtle to establish a computer router with a disk drive and a startup file that sets up the local files on the new computer correctly.

[robhol]

Tried again using the new version. I can connect and send data, but apparently not connect, send, reconnect and send more, the client freezes after trying to send batch #2.

Net shell didn't work, I get "connection:298:expected number, number" on the client, the server says "remote command ls" like expected.

Have you, by the way, considered something UDP-like? If I just want to send a packet without messing around with connections etc.

[Lyqyd]

robhol, on 11 October 2012 - 05:26 PM, said:

Tried again using the new version. I can connect and send data, but apparently not connect, send, reconnect and send more, the client freezes after trying to send batch #2.

Net shell didn't work, I get "connection:298:expected number, number" on the client, the server says "remote command ls" like expected.

Have you, by the way, considered something UDP-like? If I just want to send a packet without messing around with connections etc.

Heh. I'm an idiot. Didn't put "open" in quotes when setting the connection status, when you re-open a connection. That'd be a good thing to do. Corrected code:

local connections = {}

while true do
    --wait for input from client connections on socket 21.
    conn, messType, message = connection.listen(21)
    --okay, we have a packet, see if the connection is one we already
    --know about.
    if connections[conn] and connections[conn].status == "open" then
        --we can use additional entries in our 'connections' table
        --(which is internal to the server app) to store information
        --about client state, among other things.
        if messType == "data" then
            --handle client input here; use the connection number in
            --'conn' to send data back.
            print(message)
            connection.send(conn, "done", "OK")
            --break packet tells the client we are done transmitting
            --and are ready for the next command. This is optional. Some
            --types of servers wouldn't need to use this, e.g. a chat
            --server.
        elseif messType == "close" then
            --client has closed the connection, so let's close out
            --the connection information.
            connection.close(conn, disconnect, true)
            connections[conn].status = "closed"
            connections[conn].name = nil
        elseif messType == "instruction" then
            --these are local instructions. Often unused.
            if message == "stop" then
                return true
            end
        end
    elseif messType == "query" then
        --a client wants to open a connection
        if connections[conn] then
            --already have an entry for that connection number,
            --reset the information
            connections[conn].status = open
            connections[conn].name = connection.name(conn)
        else
            --no entry for this connection number, set up a new
            --entry.
            local connect = {}
            connect.status = "open"
            connect.name = connection.name(conn)
            table.insert(connections, conn, connect)
        end
        --either way we set up the connection, let the client know
        --it was successful.
        connection.send(conn, "response", "ok")
    end
end

Net shell works fine here. That error looks like it would be a malformed term.setCursorPos being sent to the client, which is unusual. I'll look into that a bit further. What are the contents of the directory you were trying to list? Perhaps there's an issue with certain sizings that tabulateCommon() does in the textutils library. I'd love to reproduce that error if I can.

I suppose free packet exchange is a possibility (a hacky workaround for this problem is used in my GPS modification; the PING packet is an attempt to connect to the GPS servers, the response is a connection-close packet; this is only good for single-packet exchanges). There is already a way to receive packets on a given port without futzing about with connections, though it leaves you on your own to sort out the header from the body of the message. Adding a connectionless send shouldn't be too hard (and will allow sending through any of computer label, route number (internal stuff), or computer ID, just like connection.open). I'll try to throw that together this weekend too, depending on other time constraints.

[robhol]

Haha, awesome. I'll give it a try later on.
I didn't change the directory, so it's the root dir or whatever's default.