ppegusii/cs677-smart-homes-iot

Programming Assignment 1: Internet of Things and Smart Homes

cs677-smart-homes-iot's Issues

API differences

How do we plan to merge our APIs? Your RegisterParams are a bit different from mine in that you are using strings and I am using ints. I wanted to stay away from strings, especially non-constants, to avoid spelling mistakes and reduce data transmitted. Also I thought that we could store all the shared struct definitions in one place to avoid circular imports and repeated code. The gateway seems best because that's the thing that needs to know about them all. What do you think of gateway/api.go?

Notify each replica of assigned nodes.

Map of node IDs. Replica should filter actions based on map entries.

Paxos implementation

If possible paxos implementation

Failure while registration after one replica goes down or when one replica is not up

a) start gateway on port 6770
b) register temperature sensor it gets device id 0
c) now, start replica 9999
d) register motionsensor it also gets device id 0

implement sendState in push sensors

Paxos writeup

Paxos writeup the last part of the assignment

Gateway gives same device ID while registering

Gateway always returns device ID 0 while registering.

Test case: 1

Steps to reproduce:

1. Start Temperature Sensor. When temperature sensor starts , it starts with temperature 0 degree
2. Now, start Smart outlet. It starts with a state "Off"
3. Now, unless there temperature sensor temperature goes above 2 and then drops down below 2 the outlet state remains "Off".

Expected Behavior:

Shouldn't the Smart Outlet state be turned to "On" after Step 2 above.

RPC call to change gateway to send state and other events to

RPC function that changes the current gateway to communicate with

Register all sensors and devices with gateway

Register all sensors and devices with gateway

Design Decision: Middleware

1. All call (broadcast, to individual nodes) would be made by each application via the Middleware.
   Middleware intercepts each call and keeps a track of the current devices registered etc. Main reason is for cleaner code, reduce redundancy of code and primarily applications do not need to track the device type and other details while broadcasting messages or taking to a particular device

Leader Selection Algorithm

For Leader Election Algorithm using Bully Algorithm with device ID as the decision maker (where Gateway has the highest Device ID) seems apt. It sounds kind of monotony that gateway always wins but that should be the case because:

Reasons:

1. The entire system falls apart if Gateway goes dead
2. Broadcasting the messages and receiving the "I am alive" acks from devices/sensors is easier at the gateway since it is directly connected to all other devices/sensors/user/database.

Design document update

Update the design document with design decisions, diagrams, etc

Design Decision: Polling time to check if leader is alive

Usually it is n * no. of hops to reach the farthest peer. In this case, since each peer is connected to all others. The polling is small right now of 5 secs... will see if there is too much congestion then will increase it.

Assigned devices lost during consistency synchronization.

To fix, be sure that registering devices are a additive action only. When rebalancing, pull registered devices from the database.

Registration multicast issues

Nodes fail during registration because at least one registration request will always error and the code calls log.Fatal on error.

I changed temperature sensor to work, but the other sensors and devices need to be fixed.

Register Params struct changed

changing the struct to:

type RegisterParams struct {
Type Type
Name Name
//Cannot get caller IP from rpc library.
//Might as well send listening port too.
Address string
Port string
// ListenSocket net.TCPAddr
}

Reason: ListenSocket of type net.TCPAddr is difficult to create after finding out the sensor's IP and port where it would listen.

Register Ack from gateway

Get id and gateway address and gateway port to send subsequent requests to

Manual changes in device and sensor states

Create a screen for manually updating device and sensor states.

Caching

Caching implementation

Smartoutlet Registration

Pending functionality:
Add code for smartoutlet registration. Update the smartoutlet Deviceid field with the valye send by gateway.

All devices and sensors multicast Registration request

1. Parse the gateway IP and ports
2. Dial to gateways and send RPC register request

Devices should send current state to register.

Working on it.

Simplifying assumptions

Assuming the following to simplify structs in RPCs or limit the number of different RPCs.

• QueryState on sensors/devices will only be called by the gateway on temperature sensors.
  • Possibly rename to QueryTemperature?
  • Ended up having to query the motion sensors.
• ReportState on the gateway will only be called by motion sensors.
  • Possibly rename to ReportMotion?
• The gateway will not QueryState on devices before calling ChangeState. The gateway will assume that if the state it requests is the devices current state, then the ChangeState call is basically a no-op.

Is this OK. I think we can accomplish everything needed with this. Have I overlooked something?

Failure to start when one replica goes down

a) both replicas are up and register motion sensor, temperature sensor
b) now, leader replica 9999 goes down
c) try registering door sensor

doorsensor ameetrivedi$ ./doorsensor
2015/05/07 09:18:55 Calling error to 127.0.0.1:6770 for Gateway.Register: Inactive gateway replica: {Address:127.0.0.1 Port:6770}
2015/05/07 09:18:55 Dialing error to 127.0.0.1:9999 for Gateway.Register: dial tcp 127.0.0.1:9999: connection refused
2015/05/07 09:18:55 Could not register with a gateway.
doorsensor ameetrivedi$

Timestamps for events generated by devices and sensors

If timestamp is added in the regparam of each RPC call, will gateway handle it that way or something else needs to be done for the timestamp?

testing bug 1: sendState() call in ChangeState() gives panic

Now, sendstate() is an RPC call and no more going through
In test: tests/motion_home.json there is a call to sendstate() from Changestate() which results in panic.

2015/05/07 05:55:15 Current state: Motion
panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xb code=0x1 addr=0x20 pc=0x3e96]

goroutine 9 [running]:
main.(_MotionSensor).sendState(0xc2080c8000)
/Users/ameetrivedi/Desktop/Amee/Projects/CS677/Lab2/src/github.com/ppegusii/cs677-smart-homes-IoT/motionsensor/motionsensor.go:194 +0x196
main.(_MotionSensor).ChangeState(0xc2080c8000, 0xc20801f2c0, 0xc20801f400, 0x0, 0x0)
/Users/ameetrivedi/Desktop/Amee/Projects/CS677/Lab2/src/github.com/ppegusii/cs677-smart-homes-IoT/motionsensor/motionsensor.go:128 +0x20d
reflect.Value.call(0x329960, 0x394d70, 0x13, 0x3c6190, 0x4, 0xc2080a3f28, 0x3, 0x3, 0x0, 0x0, ...)
/usr/local/go/src/reflect/value.go:419 +0x10e5
reflect.Value.Call(0x329960, 0x394d70, 0x13, 0xc2080a3f28, 0x3, 0x3, 0x0, 0x0, 0x0)
/usr/local/go/src/reflect/value.go:296 +0xbc

Progress list

Registration from sensor/device done

Database design

• 1 file for registration since this will only be accessed once.
• 1 state file and 1 event file per device or sensor
• We chose this because of:
  • Less lock contention than 1 state file and 1 event file for all devices
  • Searching for the latest device state would involve only an offset seek to the end of the file, but we will cache the latest state in memory anyways.

Add comments in the existing code

Add comments everywhere in the current code

gRPCPort and gRPCIp synchronize access

Could add a synchronized struct in structs.go, such as SyncString, similar to SyncBool. Using the existing SyncRegGatewayUserParam might be easier.

IP guessing in main.go

Why guess the IP? If there are multiple interfaces, an incorrect guess is possible.