| | 457 | ==== 1/15 ==== |
| | 458 | Several points to rehash: |
| | 459 | |
| | 460 | * There's only so many layers you want to add to the hierarchy, as it implies delay in service. |
| | 461 | |
| | 462 | * In theory, we want any component to be able to escalate something. |
| | 463 | |
| | 464 | * Listeners for switch join/leave events are probably looking for topology transparency. That implies that they also need FEATURE_REPLY and PORT_STAT messages, and that the DStream entity needs to maintain some sense of what is there. So, the DStream entity should have a way to track the switches that are below the client it represents, and a way to be passed as the correct switch to the modules looking for PacketIns. |
| | 465 | * The switches themselves need to be able to alias write() with DStream's, so it has a way to recover the context of TID, and to send it back as a CPLMessage. |
| | 466 | * So CPLSwitchImpl > OFSwitchImpl, and CPLDStream (re-name for relevance) as a shim with its own context for keeping track of TID (CONTEXT_TID). |
| | 467 | |
| | 468 | * Tracking TID - hopefully possible through the context, though not under all cases to IOFSwitch.write(). A quick glance shows that as long as write() is called through receive(), the context can be preserved. |
| | 469 | |
