Jump to content




[Dead Project] [ver=ALPHA]GPS based IP relay System "GP-IS"(working Internet in minecraft)


20 replies to this topic

#1 BigSHinyToys

  • Members
  • 1,001 posts

Posted 19 March 2012 - 04:46 PM

Posted Image
first off hi all
this is the second post i am making on these forums. I have only a limiteds experience with hobby programing in BASIC and a very small amount of C++ experience. I started learning lua about start of year or so. This is the first program that i am posing ( I have many that are not up to scratch that i wont post EVER )

down to business

GPS based IP relay System or "GP-IS" for short
Spoiler
How to use

If you are experienced please conceder helping me by bug testing thank you in advance

This is for experienced lua programmer only at the moment for bug testing
this is very complex code and is currently buged / hard to operate

Spoiler
BUT this needs a stable location how does it work for turtles ?
Spoiler
To conclude this wall of text.

This system of packet routing could revolutionize the way data is transfered long distance in a minceraft world. If you have the time and experience i would really appreciate anyone testing this as it realy needs to be on a server to really be tested.

please post bug reports here with as mutch info as possible

Picture one my GPS tower services GPS requests.
Spoiler

NEW Latest testing candidates.


node 0.25
Spoiler

cnode 0.31
Spoiler

nodeFTP ( a command line file transfer application ) 0.24 built on cnode 0.31
Spoiler


#2 BigSHinyToys

  • Members
  • 1,001 posts

Posted 21 March 2012 - 08:12 PM

I have fixed some major bugs

fixes
- client side computers "cmprec" no longer cause node crash from broadcasting
- stability major improved adjusted sleep timers ( still needs refinement )
- actually works properly now ( this was a big bug :(/> )

added
- nodes now will try a different node it it receives no confirmation. and will remove it from routing table.
- nodes log every rednet event to a log table ( this will be saved to file in a latter ver for error testing )
- nodes will display all connected computers by pressing t and all avalible nodes by pressing y alos all packets by pressign u and finally all loged events by pressing r


feel free to try the new alphas they are almost read to go full ver.

A few reasons to try it.
- Security it is impossible to collect your data off the air.
- it is impossible to spoof being another computer successful
- prefect for SMP ( maybe i a few vers time )





Big Shiny Toys

UPDATE SUN March 24th 2012 4:41 AM

Posted Image
First Message send from node to cnode then new client interface.
cnode will feature a function that works exactly like os.pullEvent() but it will decore the destination IP and return only the ID of the snender the Data the distance ( as you see it is future than 65 block limmit ) and finaly return nodeNet as a fifth value. all other rednet messages will be returned as is and all other events will work as before. I am close to a full release and after adding a nodeSend function should be ready. if not this weekend then next (Very bussy this week)


Big Shiny Toys

#3 BigSHinyToys

  • Members
  • 1,001 posts

Posted 28 March 2012 - 02:41 PM

- snip -

#4 Liraal

  • New Members
  • 477 posts
  • LocationPoland

Posted 28 March 2012 - 02:43 PM

add [spoiler] tags to make reading it easier.

#5 Ian-Moone

    The Germ

  • New Members
  • 124 posts
  • LocationLiverpool (no I am not a Scouser Im form Holland)

Posted 28 March 2012 - 08:07 PM

looking good ill keep my eye on this

#6 tommyroyall

  • Members
  • 136 posts

Posted 30 March 2012 - 12:41 AM

Nice man. I can just imagine setting a GPS tower up in my village and using a packet based mesh networking system to link it up to another village.

#7 Jojo.bacon

  • Members
  • 20 posts

Posted 02 April 2012 - 08:52 PM

I think that this is a great system, but it should be able to route regular rednet messages whithout too much setup on the client computer. That way programs that use regular rednet will be compatible. Maybe you could use a program that would register the client with the node when you run it.

#8 BigSHinyToys

  • Members
  • 1,001 posts

Posted 03 April 2012 - 07:02 AM

View PostMrjoecool123, on 02 April 2012 - 08:52 PM, said:

I think that this is a great system, but it should be able to route regular rednet messages whithout too much setup on the client computer. That way programs that use regular rednet will be compatible. Maybe you could use a program that would register the client with the node when you run it.
cnode the Client side node package does register all IP that send data to it. so for s sever it will always be able to reply to incoming message. as for the user side they would need to enter an address ounce and it will be stored. after an address is stored it can be referenced by its ID as the computer knows its address. this is to help with backwards compatibility with other software systems. But I would still need to tailor the system for each program as there is a lot more node can offer. for example to authenticate a user that is login on you could compare the GSP IP tag with the one they used last and if different refuse connection. or ignore packets from users that are not logged in.

I am currently working on some end user applications that use node I have a very basic FTP sever/client set up. it is currently command line operated.

New vers released.

#9 ChunLing

  • Members
  • 2,027 posts

Posted 15 October 2012 - 04:42 PM

I was working on a rednet forwarding host to replace the standard gps host program. It has some functionality that you might find useful. Right now it just allows the node running it to respond to a couple of messages other than "PING", but the code is written so that you can easily expand the variety of messages it can take. And the basic forwarding method itself could be useful for setting up stable communication over a distance.
Spoiler
The key functionality is defined for messages that take the form of ("RELAY:"..ID), where ID is a number ID for the computer that will receive relays of further messages from the sender. Once a relay has been successfully started in host mode (arguments are the same as for gps host setup), it writes a startup file so that it will restart with the same position information. A separate file is used to track the current forwarding table.

FINDHOSTS doesn't work reliably, the table of available node data gathered is printed out on the node terminal but doesn't get sent back to the requesting terminal in a timely fashion. This can probably be corrected by shortening the timeout for collecting node responses to it's PING, but may or may not affect quality of the host information gathered. It should also be solved by just having the requesting terminal wait longer for an answer. Which solution is better for your needs is up to you, I think.

You can define any number of other functions that will be called by a specific rednet string, simply adding them to hstfnc{}, as long as they do not require information other than the global variables defined in the program (all the information from the rednet message calling the function is available this way, though the message itself is already used to identify the function, so you only have the sender ID and the distance).

While the relay function currently only accepts one to one connections (a two-way relay between two computers) and a broadcast mode (accessed by setting the node ID as the relay value), it can be modified with relative ease by using a second layer table to hold multiple forwards for each ID. But that introduced a difficulty deciding whether to try to relay or execute "RELAY:ID" commands, so I just dropped it. But I guess the second table could be indexed by the ID and contain a value specifing the type of recipient, i.e. whether it was a relay node or not. But the IP address idea seems like it would also be a good way to solve that question.

Sorry, I fell asleep while posting.

#10 Sebra

  • Members
  • 726 posts

Posted 15 October 2012 - 06:12 PM

Shouldn't you define "sndr" at the top of program?
Other vars probably should be defined upper, then first read too.

#11 ChunLing

  • Members
  • 2,027 posts

Posted 15 October 2012 - 07:30 PM

Lua allows you to define global variables anywhere. Some people find this inconvenient, I sometimes think it is a bit obscure myself. But the logic is clear, it makes the language inherently very robust. So the answer is no, you shouldn't define global variables before you need them, but you also need to be careful not to use global variables by accident.

Which I haven't, as far as I know.

#12 BigSHinyToys

  • Members
  • 1,001 posts

Posted 16 October 2012 - 04:26 AM

This was one of my first programs and as such is incredibly badly coded. I am working on a new implementation of the basic GPS bases packet routing system as of yet there is no fixed date for its release. but seeing your interest in the my program here is a preview.
http://pastebin.com/fUrCNDUK

This shows netALPHA in a practical demonstration with a turtle allowing all turtles to both be receivers and transmitters making any turtle in range of one other connected into the network. also it has a hop embedded in the packet header table. As you can see it is far from completion.

#13 ChunLing

  • Members
  • 2,027 posts

Posted 16 October 2012 - 07:21 PM

I favor an approach of having the turtle/host side programming be very simple, but passing enough information back to the controller to allow it to tell everything it needs to know. For instance, the clfn remote control program goes ahead and sends back the result of any turtle API command you pass it, so you know whether or not the movement succeeded, how many items you sucked up, etc. There is also a gps location command, so the turtle tells the controller where it is (or that it can't tell where it is). If a move fails, then you can have the computer send the rctfncs command (like dfd), which will either work or give more specific feedback on why the turtle can't move ("unbreakable block in path", "Out of fuel", or "persistent impediment"). From that information the central controller can track the "inertial" location of the turtle if necessary.

I hope to apply the same kind of principle to the relay hosts, so that they are basically controlled by just a few simple commands over rednet.

Then it is just a matter of controlling the central computer to do something with all those turtles and hosts. Which is the hard (or fun, I guess it depends on perspective) part. The key is making sure that the turtles and relays can give all the useful feedback the central controller really needs.

I rather like the physical address idea, though given that the central computer can get all the locations of any relay or turtle it is in contact with, it can probably work out the best communication rout itself.

#14 BigSHinyToys

  • Members
  • 1,001 posts

Posted 17 October 2012 - 11:56 AM

View PostChunLing, on 16 October 2012 - 07:21 PM, said:

I favor an approach of having the turtle/host side programming be very simple, but passing enough information back to the controller to allow it to tell everything it needs to know. For instance, the clfn remote control program goes ahead and sends back the result of any turtle API command you pass it, so you know whether or not the movement succeeded, how many items you sucked up, etc. There is also a gps location command, so the turtle tells the controller where it is (or that it can't tell where it is). If a move fails, then you can have the computer send the rctfncs command (like dfd), which will either work or give more specific feedback on why the turtle can't move ("unbreakable block in path", "Out of fuel", or "persistent impediment"). From that information the central controller can track the "inertial" location of the turtle if necessary.

I hope to apply the same kind of principle to the relay hosts, so that they are basically controlled by just a few simple commands over rednet.

Then it is just a matter of controlling the central computer to do something with all those turtles and hosts. Which is the hard (or fun, I guess it depends on perspective) part. The key is making sure that the turtles and relays can give all the useful feedback the central controller really needs.

I rather like the physical address idea, though given that the central computer can get all the locations of any relay or turtle it is in contact with, it can probably work out the best communication rout itself.

I have been working form a different prospective of making each node / repeater its own platform and creating a meshnet where all computers / turtles run the same program in the background. this eliminates the bottleneck at the one central computer and also loaded chunk problems. but mine was designed to one day be part of a turtle army / swarm. where I would not be interacting with the system at all and it would need to finds its own way. The GPS IP system is something that i came up with to make routing of packets easer as you could use math to work out the real shortest route. I think it could have real world applications in smart phone meshnets.

#15 brett122798

  • Members
  • 298 posts
  • LocationIn the TARDIS at an unknown place in time.

Posted 17 October 2012 - 03:04 PM

Abandoned? Seemed like a good idea..

#16 BigSHinyToys

  • Members
  • 1,001 posts

Posted 17 October 2012 - 03:19 PM

View Postbrett122798, on 17 October 2012 - 03:04 PM, said:

Abandoned? Seemed like a good idea..
GP - IS is abandoned the idea of using GPS coordinates as a IP address is not I will be releasing a new better system based on that idea called netALPHA it is built into TAMS witch I posted above. I have no fixed release date for it as of yet.

GPS based IP routing is not a propriety system If you or anyone else would like to make your own packet routing system using that concept please do Information wants to be free.

#17 ChunLing

  • Members
  • 2,027 posts

Posted 17 October 2012 - 04:07 PM

For now I'll probably be sticking to what is useful in the area of world chunks loaded around the player (me) when I'm at my central terminal. The idea of a fully automated swarm seems fun but too potentially damaging...maybe one day I'll unleash one on an isolated area a few kilometers from my base.

#18 BigSHinyToys

  • Members
  • 1,001 posts

Posted 17 October 2012 - 05:25 PM

If swarms are ever created they would be quite the persistent and dangerous Nemesis testing them in another world would be a much safer option and building in a rednet "kill" command just in case.

#19 Sebra

  • Members
  • 726 posts

Posted 17 October 2012 - 06:22 PM

View PostChunLing, on 15 October 2012 - 07:30 PM, said:

Lua allows you to define global variables anywhere. Some people find this inconvenient, I sometimes think it is a bit obscure myself. But the logic is clear, it makes the language inherently very robust. So the answer is no, you shouldn't define global variables before you need them, but you also need to be careful not to use global variables by accident.

Which I haven't, as far as I know.
Try it, please. :D/>
Imho you still need to write or define above first read.
I think that leads to "no sender id for too early defined functions".

#20 ChunLing

  • Members
  • 2,027 posts

Posted 17 October 2012 - 07:37 PM

Oh, I'm already running this code on all the gps hosts in my main game world.

The only "problem" is that after you exit the host you can still access the global variables, so someone can get themselves up to my GPS array, terminate the relay program, and then use lua to access the tables holding the relay information or the variables holding information from the last message received. But they can get the relay information from the stored file anyway, and the variables only hold the last message processed...which might be a vital bit of intel, I admit.





1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users