- Sat Mar 26, 2016 10:23 am
#44079
Very impressive, CiccioCB!
No rush for beta code, I'd rather be patient and wait for captain MMisCool to brings things tidily together. Following your 'already working on it" msg, I ordered some Sonoffs last night with the planned intention of being able to control them directly from other ESP Basic udp trigger nodes (switches and PIRs etc), which could hopefully offer users a practical working interconnectivity example when done. First though, while waiting their arrival, I need to get to grips to learn ESP Basic (it's been over a quarter of a century since I last used Beeb Basic).
My own udp messaging efforts (arduino c++ version) suggested there were 4 different types of udp 'messages' that might be required...
1. Announcement Broadcast with no response needed (eg: Hello world) by sending to destination address 255 without including the source address.
2. Enquiry Broadcast expecting a Response (eg: Who's there?) by sending to dest 255 and including the source address to respond to.
3. Reply to Sender expecting a Response (eg: Yes I'm here, what do you want?) by sending to dest addr and including source addr.
4. Reply to Sender with no further response needed (eg: Your msg received ok, over and out) by sending to dest addr without including source addr.
Although not essential, it could improve reliability if some sort of 'response timeout' could be incorporated to allow a 'sender' to re-transmit any failed acknowledgement msgs -perhaps 'n' amount of times - before giving up and taking some other action (like logging the failure). Another thing I was considering was including a unique msg ID (perhaps based on original transmit time) so that any late out-of-step incoming replies could still be tracked and correctly responded to. And perhaps nodes each having a unique 'courtesy' response delay based somehow on their addresses so that their responses are slightly staggered, preventing all trying to respond immediately to broadcast requests and swamping each other - just thoughts in my head, don't know if it's actually necessary with ethernet or not.
And looking at your list of proposed udp commands I'm sure you're already way ahead of me, I just thought it worth mentioning such things now in case anything is relevent.
Your 'udpbranch label' is a great idea by the way, and should make actioning of incoming locally-recognised network commands and parameters an absolute doddle (presumably it will just need to match and branch to the command substring part of an incoming msg so that the branch can deal with any accompanying parameters substring).
Really great work guys, there's sure to be some good stuff done with this.
No rush for beta code, I'd rather be patient and wait for captain MMisCool to brings things tidily together. Following your 'already working on it" msg, I ordered some Sonoffs last night with the planned intention of being able to control them directly from other ESP Basic udp trigger nodes (switches and PIRs etc), which could hopefully offer users a practical working interconnectivity example when done. First though, while waiting their arrival, I need to get to grips to learn ESP Basic (it's been over a quarter of a century since I last used Beeb Basic).
My own udp messaging efforts (arduino c++ version) suggested there were 4 different types of udp 'messages' that might be required...
1. Announcement Broadcast with no response needed (eg: Hello world) by sending to destination address 255 without including the source address.
2. Enquiry Broadcast expecting a Response (eg: Who's there?) by sending to dest 255 and including the source address to respond to.
3. Reply to Sender expecting a Response (eg: Yes I'm here, what do you want?) by sending to dest addr and including source addr.
4. Reply to Sender with no further response needed (eg: Your msg received ok, over and out) by sending to dest addr without including source addr.
Although not essential, it could improve reliability if some sort of 'response timeout' could be incorporated to allow a 'sender' to re-transmit any failed acknowledgement msgs -perhaps 'n' amount of times - before giving up and taking some other action (like logging the failure). Another thing I was considering was including a unique msg ID (perhaps based on original transmit time) so that any late out-of-step incoming replies could still be tracked and correctly responded to. And perhaps nodes each having a unique 'courtesy' response delay based somehow on their addresses so that their responses are slightly staggered, preventing all trying to respond immediately to broadcast requests and swamping each other - just thoughts in my head, don't know if it's actually necessary with ethernet or not.
And looking at your list of proposed udp commands I'm sure you're already way ahead of me, I just thought it worth mentioning such things now in case anything is relevent.
Your 'udpbranch label' is a great idea by the way, and should make actioning of incoming locally-recognised network commands and parameters an absolute doddle (presumably it will just need to match and branch to the command substring part of an incoming msg so that the branch can deal with any accompanying parameters substring).
Really great work guys, there's sure to be some good stuff done with this.
