Theory
એક જ hostel, બે રીતે દોરેલો
પાછલા પાઠમાં SmartHostel ને physically દોર્યું હતું: આ sensor, એ cable, એ protocols.
હવે brand names કાઢી નાખો અને એને ફરી દરેક part શું કરે છે એ રીતે દોરો: કંઈક sense કરે છે, કંઈક carry કરે છે, કંઈક serve કરે છે અને કંઈક guard કરે છે. આ બીજું drawing એ logical design છે: blueprint જે આવતીકાલે દરેક physical part swap થાય તો પણ true રહે છે.
એના બે halves છે જે exam ને બહુ ગમે છે: 6 functional blocks અને machines વચ્ચે થઈ શકે તેવી conversation ની 4 shapes.
At a glance
6 functional blocks
| Block | Job | SmartHostel face |
|---|---|---|
| Device | Sense, actuate, monitor | Tank float, gas detector, gate motor |
| Communication | Blocks વચ્ચે data carry કરવો | WiFi + MQTT machinery |
| Services | Monitoring, control, data publishing, discovery | Read-tank-level service; start-pump control |
| Management | System govern અને configure કરવો | 20% threshold set કરવો; room 214 નો sensor add કરવો |
| Security | Authentication, authorization, data protection | માત્ર warden નું login gate ખોલી શકે |
| Application | User-facing interface | Dashboard અને તેનો red tank icon |
Theory
Machine conversation ની ચાર shapes
Devices અને servers 4 standard patterns માં વાત કરે છે અને સાચી pattern પસંદ કરવી syllabus સીધી test કરે છે:
- Request-Response: Client પૂછે છે, server answer કરે છે, done: દરેક exchange independent છે (stateless)
- Publish-Subscribe: Senders broker પર topics માં publish કરે છે; interested લોકો subscribe કરે છે: sender અને receivers ક્યારેય મળતા નથી
- Push-Pull: Producers queues માં messages push કરે છે; consumers પોતાની speed પર pull કરે છે: queue speed differences absorb કરે છે
- Exclusive Pair: Exactly 2 parties વચ્ચે ONE persistent, full-duplex, stateful connection હોય છે, જે deliberately close થાય ત્યાં સુધી open રહે છે
Theory
Hostel પહેલેથી વાત કરે છે એવી ચાર રીતો
Request-response warden ના door પર એક question સાથે knock કરવા જેવું છે: answer મળ્યો, door shut.
Publish-subscribe notice board જેવું છે: mess menu pin કરે છે (topic "mess" પર publish કરે છે), જેને care હોય એ વાંચે છે; cook ને કોણે જોયું એની ખબર નથી.
Push-pull dhobi ની basket જેવું છે: residents કપડાં drop કરે છે (push); dhobi પોતાની speed પર basket empty કરે છે (pull): basket Monday નો pile-up absorb કરે છે.
Exclusive pair phone call પરના બે friends જેવા છે: line open છે, બંને વાત કરે છે, કોઈ hang up કરે ત્યાં સુધી.
At a glance
4 communication models, technically
| Model | Middleman | State | SmartHostel use |
|---|---|---|---|
| Request-Response | None: direct ask-answer | દરેક exchange માં stateless | App server ને પૂછે છે: current tank level? |
| Publish-Subscribe | Topics સાથે BROKER | Broker subscriptions track કરે છે | Sensors hostel/tank publish કરે; dashboard + logger બંને subscribe કરે |
| Push-Pull | Messages buffer કરતો QUEUE | Queue backlog રાખે છે | દર મિનિટે meter readings push થાય; analytics hourly pull કરે |
| Exclusive Pair | None: એક held line | Fully stateful connection | Guard ની screen પર live gate camera feed |
Quiz
Tank sensor ના readings dashboard, data logger અને new leak-detection service સુધી પહોંચવા જોઈએ, પરંતુ sensor ને એમમાંથી કોઈ exist કરે છે એની ખબર ન હોવી જોઈએ. કયો communication model?
- Request-Response: દરેક service sensor ને સીધું પૂછે
- Publish-Subscribe: sensor topic પર publish કરે; broker પર ત્રણેય subscribe કરે
- Exclusive Pair: sensor 3 permanent connections hold કરે
- Push-Pull: ત્રણ services turn લઈને pull કરે
Show the answer
Publish-Subscribe: sensor topic પર publish કરે; broker પર ત્રણેય subscribe કરે
One source, ઘણા independent listeners, mutual anonymity: આ publish-subscribe ની exact shape છે. Sensor hostel/tank/level broker પર publish કરે છે અને sleep કરે છે; broker દરેક subscriber સુધી એને fan out કરે છે. આવતા મહિને fourth listener add કરો તો sensor માં કશું બદલાતું નથી. Option A નાનાં device ને 3 clients serve કરાવે છે અને દરેકને poll કરવું પડે. Option C જરૂર વગર 3 held lines વાપરે છે; exclusive pair continuous 2-party streams માટે છે. Option D ની queue દરેક message ONE consumer સુધી પહોંચાડે છે (workers jobs share કરે છે), બધાને copies નહીં. આ pub-sub vs push-pull distinction exam સીધું test કરે છે.
Think first
State બાબતે odd one out કયો?
ચાર models માંથી એક end-to-end STATEFUL હોવાથી define થાય છે: connection પોતે remember કરે છે. તેનું નામ આપો, stateful હોવાથી શું મળે એ સમજાવો અને physical-design lesson ના protocol સાથે જોડો. પછી tap કરો.
Show the answer
Exclusive pair: એક held connection જ state છે. બંને ends જાણે છે કે line open છે, line પર કોણ છે અને શું flow થયું છે. આ BOTH directions માં instant, no-handshake, full-duplex messaging આપે છે, એટલે live camera feed અથવા real-time gate console માટે perfect છે. તેનો physical-design twin WebSocket છે, જેમ MQTT publish-subscribe ને embody કરે છે. Logical models shapes છે; protocols એ shapes ની implementations છે. Request-response એની વિરુદ્ધ deliberately STATELESS છે: દરેક exchange standalone, cheap, simple અને forgetful by design.
Watch out
Logical-design slips
Blocks vs layers: 6 functional blocks 4 architecture layers નથી. Blocks FUNCTION દ્વારા slice કરે છે; layers data ની JOURNEY દ્વારા. બે અલગ diagrams છે અને બંને examinable છે.
Pub-sub vs push-pull: Topics ALL subscribers ને copies fan out કરે છે; queues દરેક message ONE puller ને આપે છે: broadcast vs work-sharing.
Security ને છેલ્લે mention કરાતો block માનવો: એ ALL blocks, એટલે કે device થી application સુધી, span કરે છે. Cross-cutting કહો અને એનો અર્થ જાણો.
Theory
Unit 1 closes: frame તૈયાર છે
ચાર lessons પછી આખું frame તમારી પાસે છે: IoT શું છે (definition વત્તા 5 characteristics), reading કેવી રીતે travel કરે છે (4 layers), parts શું છે અને કેવી રીતે બોલે છે (things વત્તા 3 protocol families), અને conversations કેવી રીતે shape થાય છે (6 blocks, 4 models). બાકીના બધા units આ frame પર details લટકાવે છે. Unit 2 IoT ના older sibling, એટલે કે M2M, સાથે શરૂ થાય છે અને exam નું favourite comparison પૂછે છે: internet એ ખરેખર શું ઉમેર્યું?
Summary
Key takeaways
- Logical design hardware choices થી independent રહીને system ને function દ્વારા describe કરે છે.
- છ functional blocks: device, communication, services, management, security (cross-cutting) and application.
- Request-Response: stateless ask-answer, middleman નહીં: web ની shape.
- Publish-Subscribe: broker + topics; publisher અને subscribers ક્યારેય મળતા નથી: MQTT ની shape; ALL subscribers ને copies.
- Push-Pull: queues producer અને consumer rates વચ્ચે buffer કરે છે; દરેક message ONE puller સુધી.
- Exclusive Pair: એક persistent, stateful, full-duplex line: WebSocket ની shape.
- Memory hook: knock, notice board, dhobi basket, phone call.