Rednet not communicating... after it communicates.

I have two computers, they are sended (encrypted) information to each other. One of these computers is a server, the other is a client. The client sends a command to the server and it responds with information. Then, if the client sends the command again then the server never responds or even receives the message. If the server restarts but the client does not then the server says it receives the message and it has responded but the client never receives the message.

The client was made to test the server, not as a fully functional client and the server was created to handle bank accounts. The code for the client is here and the code for the server is here.

Both programs load some API's when they are ran. The two APIS are 'hashing' and 'randcrypt' (randcrypt loads this 'random' API)

In advanced, thank you for your help and patience.

Use os.pullEvent instead of rednet.receive

Like Creator said,just use os.pullEvent like this:

while true do
 local sender,data=os.pullEvent("rednet_message")
 if sender == "MeredithBank" then
  local rednetData = { data }
  -- your code here
  end
end  

I tried this but the errors remained

Is the code erroring too?

Creator, on 30 October 2015 - 06:15 AM said:

Use os.pullEvent instead of rednet.receive

Why would you expect that to make a difference?

C'mon, dude. You're a fairly competent programmer, so I'm more than a bit curious as to what your train of thought was there.

Throwing out "guesses" as if they were "solutions" isn't helpful, if that's what you were thinking.

Glass Systems, on 30 October 2015 - 08:50 AM said:

Like Creator said,just use os.pullEvent like this:

os.pullEvent() returns event types before the rest of the data. That's also not even remotely how you would make use of protocol strings.

@LeviM:

The problem is pixelcrypt's use of math.randomseed().

When a ComputerCraft computer boots, it picks a random seed to generate math.random() results with (presumably based on what the system clock is set to at the time the computer starts, as that's the most common source, but it could be based on something else - point is it's not immediately easy to guess, and is therefore unpredictable).

Values returned by math.random() will always follow an entirely predictable pattern so long as the seed is known. If you set the seed to 1 and generate ten "random" numbers, then set the seed to 1 again and generate another ten "random" numbers… then you'll get exactly the same results.

You, however, are setting it to something entirely predictable, within your checksum function. This has system-wide effects.

For one thing, it means that the unique identifiers attached to rednet messages your client sends - which are supposed to be random, in order to prevent messages from getting the same ones (or at least, make it really unlikely that they get the same ones) - become entirely predictable, to the point where your script will use the same UUID for the message it sends every time.

And if your server gets two messages with the same UUID within half a minute, then it assumes the extra copies were transmitted by the repeat script, and since it already got one with that UUID recently that means it ignores it.

In short, if you feel pixelcrypt.checksum() MUST use math.randomseed() with a non-random argument (and I don't see any obvious reason why it should), then at least feed it a somewhat random value (such as os.clock()) once you're done with it so that it's not so predictable afterwards!

I suggested the first thing because rednet.receive is a noobish approach and skips events. It is better to get all the events and process them the way they should be.

I think I know what it is. When you send data to the server, you serialize the table. However, when you read it server side, you treat the string like a table. That may be because the encryption api isn't working correctly and does not return a table. Also, which is the last print you see?

My bad, seems like BB explanation is the valid one.

Creator, on 30 October 2015 - 01:11 PM said:

I suggested the first thing because rednet.receive is a noobish approach and skips events. It is better to get all the events and process them the way they should be.

It's perfectly suitable for the task of receiving rednet messages, and doesn't skip valid rednet_message events.

If you want to throw out a suggestion, then you'd be better off phrasing it like one.

Sorry, I will be paying more attention to the way I phrase suggestions in the future.

Bomb Bloke, on 30 October 2015 - 01:08 PM said:

Creator, on 30 October 2015 - 06:15 AM said:

Use os.pullEvent instead of rednet.receive

Why would you expect that to make a difference?

C'mon, dude. You're a fairly competent programmer, so I'm more than a bit curious as to what your train of thought was there.

Throwing out "guesses" as if they were "solutions" isn't helpful, if that's what you were thinking.

Glass Systems, on 30 October 2015 - 08:50 AM said:

Like Creator said,just use os.pullEvent like this:

os.pullEvent() returns event types before the rest of the data. That's also not even remotely how you would make use of protocol strings.

@LeviM:

The problem is pixelcrypt's use of math.randomseed().

When a ComputerCraft computer boots, it picks a random seed to generate math.random() results with (presumably based on what the system clock is set to at the time the computer starts, as that's the most common source, but it could be based on something else - point is it's not immediately easy to guess, and is therefore unpredictable).

Values returned by math.random() will always follow an entirely predictable pattern so long as the seed is known. If you set the seed to 1 and generate ten "random" numbers, then set the seed to 1 again and generate another ten "random" numbers… then you'll get exactly the same results.

You, however, are setting it to something entirely predictable, within your checksum function. This has system-wide effects.

For one thing, it means that the unique identifiers attached to rednet messages your client sends - which are supposed to be random, in order to prevent messages from getting the same ones (or at least, make it really unlikely that they get the same ones) - become entirely predictable, to the point where your script will use the same UUID for the message it sends every time.

And if your server gets two messages with the same UUID within half a minute, then it assumes the extra copies were transmitted by the repeat script, and since it already got one with that UUID recently that means it ignores it.

In short, if you feel pixelcrypt.checksum() MUST use math.randomseed() with a non-random argument (and I don't see any obvious reason why it should), then at least feed it a somewhat random value (such as os.clock()) once you're done with it so that it's not so predictable afterwards!

I didn't make pixelcrypt, it's an API I got from a friend so…. I have no idea what any of this means.

Creator, on 30 October 2015 - 01:38 PM said:

Sorry, I will be paying more attention to the way I phrase suggestions in the future.

Bomb Bloke, on 30 October 2015 - 01:08 PM said:

Glass Systems, on 30 October 2015 - 08:50 AM said:

Like Creator said,just use os.pullEvent like this:

os.pullEvent() returns event types before the rest of the data. That's also not even remotely how you would make use of protocol strings.


And I'll make sure to check my code more thoroughly before posting :P/>.

LeviM, on 30 October 2015 - 02:11 PM said:

I didn't make pixelcrypt, it's an API I got from a friend so…. I have no idea what any of this means.

It means stick a math.randomseed(os.clock()) down the bottom of pixelcrypt.checksum(), replacing line 114.

Bomb Bloke, on 30 October 2015 - 10:33 PM said:

LeviM, on 30 October 2015 - 02:11 PM said:

I didn't make pixelcrypt, it's an API I got from a friend so…. I have no idea what any of this means.

It means stick a math.randomseed(os.clock()) down the bottom of pixelcrypt.checksum(), replacing line 114.

I did that but now there is an error on startup line 116. attempt to index ? (a number value)

In which case you may need to pick your "random" randomseed at a different time - check when checksum() is called, and have the last pixelcrypt function involved in the chain before returning control to your script pick a new seed.

Or better yet, get pixelcrypt's author to correct the original.

Bomb Bloke, on 31 October 2015 - 12:48 AM said:

In which case you may need to pick your "random" randomseed at a different time - check when checksum() is called, and have the last pixelcrypt function involved in the chain before returning control to your script pick a new seed.

Or better yet, get pixelcrypt's author to correct the original.

I thought it would be easier to just change encryption apis. However it still has the original problem of both computers having to be restarted. The API I am now using for encryption can be found here (and in that API it loads this API). For some reason it can't encrypt serialised tables or normal tables so you will find that in my code I have used some fancy methods of sending tables over rednet :D/> I have updated the pastebin links in the O.P.