Combined Rednet Sender/listener

Hello guys.
I am experiencing huge brain problems as i cant sort out how to program a combined sender/listener.
I'm trying to make an automatic sorting/retrieval system with computercraft
The purpose for my program is to use a main wireless computer where you e.g. could type "redstone" and then the computer will request a message from the computer controlling the redstone chest in the sorting system for a variable which will determine how many stacks of a given item the user wants.

The problem is, the main computer must be able to send and retrieve at all times.
What i mean is the program must not exit its while loop and neither does the listening computer (that controls a chest with redstone for example)

The key problems i'm experiencing is that i cant retrieve messages and send an input to the listening computer, whilst the listening computer also should be able to send back a message without breaking its listening loop.

--Listener
rednet.open("back")
while true do
  event, senderId,message,distance = os.pullEvent("rednet_message")
  if message == "redstone" then
    local a = read()
    rs.setOutput("left", true)
    sleep(a*3.35)
    rs.setOutput("left", false)
    print(a," redstone stacks sent")
  end
end

--Sender
rednet.open("back")
  while true do
  local sendmsg=read()
  rednet.broadcast(sendmsg)
end

I don't know if i have expressed my self clear enough as i find it quite hard to explain the concept of what the computers should be able to do.

Split into new topic.

Well.. I see that in the listening loop you have

local a = read()

Then

sleep(a*3.35)

Which means 'a' needs to be a number, And todo this you can just change the a to this when reading

local a = tonumber( read() )

And for the print I would suggest you used '..' instead

print(a .. " redstone stacks sent")

And are you getting some kind of error code? If so then please post it ;)/>

First off, understand that when a message is sent to a computer, that message goes into the event queue. You can pull it out when ever you like, but if beforehand you try to use a function that pulls events on its own, then that may well pull and discard the message so that your "rednet.receive" calls can't find them. "sleep" and most anything else that makes your program pause (eg "read()") results in the queue being emptied out in this way.

So with that in mind, there are a few ways you can do this.

One is to have the sender send its message, then wait for a message to come back. The server receives the first message, does whatever it's going to do with the redstone outputs, then when it's ready it sends a message back to the sender saying "I've finished". The sender then notifies the user that they can send another command. In this way, a message will never be sent to the server while it's already working (assuming there's only one "sender" computer on your network).

Another method would be to use the parallel API as discussed in other recent threads (eg). You run two functions at once: One which waits for rednet messages and adds them to a table, the other which inspects that table for content and does whatever tasks have been loaded in there (removing them when done). Each function gets its own copy of the event queue, so one can sleep/read/etc as much as it likes without denying the other from its rednet message events. This requires understanding of tables, but means that the server can receive job orders from multiple senders at once (or at any time) without getting confused.

A third option is to have the server ditch "read()" and "sleep()". The sender would instead specify "a" (you'd send something like eg "redstone 5"), and the server would interpret that instead of asking the user to type a number into it. Instead of sleeping the server would start a timer (through os.startTimer()), then go back to waiting for an event: If it receives any further rednet events before the timer expires, then it adds them to a table, and deals with those jobs when the when the current one is complete. This involves some understanding of dealing with events (to achieve what the second method lets you do without needing the parallel API), but since no one needs to go off and type stuff into the server directly, working out a system whereby all the typing is done at the sending system is most ideal.