EmotiBit / ofxEmotiBit

OpenFrameworks library and examples for the EmotiBit
MIT License
34 stars 8 forks source link

minor fix to change behavior of IP sweep in unicast #181

Closed nitin710 closed 1 year ago

nitin710 commented 1 year ago

Description

Minor fix to the protocol for IP sweep in unicast EmotiBit IP search. Expected IP sweep

for a emotibitCommSettings.json file with contents
      "sendAdvertisingInterval_msec": 1000,
      "checkAdvertisingInterval_msec": 100,
      "transmission": {
        "broadcast": {
          "enabled": true
        },
        "unicast": {
          "enabled": true,
          "ipMax": 254,
          "ipMin": 250,
          "nUnicastIpsPerLoop": 3,
          "unicastMinLoopDelay_msec": 3

expected behavior is as shown below:

Ping begin
<send Broadcast>
<start unicast pinging>
ping 250
ping 251
ping 252
<wait 3 m secs>
ping 253
ping 254
<wait 1000m secs>

in case of multiple networks

Ping begin
<send Broadcast>
<start unicast pinging>
ping x.x.x.250
ping x.x.x.251
ping x.x.x.252
<wait 3m secs>
ping x.x.x.253
ping x.x.x.254
ping y.y.y.250
<wait 3m secs>
ping y.y.y.251
ping y.y.y.252
ping y.y.y.253
<wait 3m secs>
ping y.y.y.254
<wait 1000m secs>

Requirements

Issues Referenced

Documentation update

Testing

Checklist to allow merge

Screenshots:

nitin710 commented 1 year ago

New bug? with multiple emotibits on the network Below is a sequence with each number representing IP address. The range specified is 250-254 with 3 IPs per loop

250
251
252 (EmotiBit found)
--
253
254 (sendInProgress=false)
250 (not sent) 
--
wait 1000ms
<new EmotiBit joined at 250>
--
251
252
253
--
254 (sendInProgress=false)
250  (not sent) 
251 (not sent) 
--
wait 1000ms
-- 
252 
253 
254 
--
wait 1000ms
--
250 (EmotiBit found after 3 secs of joining)
251
252
produceconsumerobot commented 1 year ago

I think this works ✅

nitin710 commented 1 year ago

Ok! merging to main