@mindbender, that's why I suggested java. The first version with hard coded packets acutally had a gui. Even had a "log"-window showing the commands in blue, errors in red and ls-answers in black. Neat, but the rest ....
For the current purpose I thought a command line tool would be fine.
The suggestion to use the CSV sounds good, do I need a special account?
I think next steps should be to create some classes e.g:
byte  buf;
set/get PcktVersion, ACPcmdtype, ConnectID, MAC, (optdatalength), optdata
ACPspacket extends ACPpacket
makeAuth (password) // encryption?
ACPrpacket extends ACPpacket
getCmd // cmd word at ,
getResult // Error code
getAnswer // string starting form
getMAC, PktVersion, ConnID
.... // what is needed to decrypt the packets
and the "main" class
Integer status // nothing, waiting for reply, timeout, error
set/get MAC, ConnID, target, sockettimeout
onReceive (ACPrpacket _AnswerPkt, ACPcmdtype _cmd) // called, when a packet is received _cmd is the originally
// sent cmd, might be handy for analysing the answer.
onDiscover (ACPrpacket _AnswerPkt // called, when a discover answer is received, e.g to fill a list
We should put the receiving part in an own thread, started when a packet is sent so that is not blocking (needed for gui). The application can then either check for the status (could make it blocking again) or it could define onReceive, onDiscover events, that are called by the receivethread on receiving a packet.
Ok, my daughter wants to play with me