| // Package stream implements interfaces in veyron2/ipc/stream. |
| // |
| // It is split into multiple sub-packages in an attempt to keep the code |
| // healthier by limiting the dependencies between objects. Most users of this |
| // package however should only need to use the Runtime type defined in it |
| // (which provides a factory method to create stream.Manager objects). |
| // |
| // Package contents and dependencies are as follows: |
| // |
| // * manager provides a factory for veyron2/ipc/stream.Manager objects. |
| // It depends on the vif and proxy packages. |
| // * vif implements a VIF type that wraps over a net.Conn |
| // and enables the creation of veyron2/ipc/stream.VC objects |
| // over the underlying network connection. |
| // It depends on the id, message and vc packages. |
| // * message implements serialization and deserialization for |
| // messages exchanged over a VIF. |
| // It depends on the id package. |
| // * vc provides types implementing veyron2/ipc/stream.VC and |
| // veyron2/ipc/stream.Flow |
| // It depends on the id and crypto packages. |
| // * crypto provides types to secure communication over VCs. |
| // It does not depend on any other package. |
| // * id defines identifier types used by other packages. |
| // It does not depend on any other package. |
| package stream |
| |
| // A dump of some ideas/thoughts/TODOs arising from the first iteration of this |
| // package. Big ticket items like proxying and TLS/authentication are obvious |
| // and won't be missed. I just wanted to put some smaller items on record (in |
| // no particular order). |
| // |
| // (1) Garbage collection of VIFs: Create a policy to close the underlying |
| // network connection (and shutdown the VIF) when it is "inactive" (i.e., no VCs |
| // have existed on it for a while). |
| // (2) On the first write of a new flow, counters are stolen from a shared pool |
| // (to avoid a round trip of a "create flow" message followed by a "here are |
| // your counters" message). Currently, this happens on either end of the flow |
| // (on both the remote and local process). This doesn't need to be the case, |
| // the end that received the first message of the flow doesn't need to steal |
| // on its first write. |
| // (3) Should flow control counters be part of the Data message? |
| // If so, maybe the flowQ should have a lower priority than that of Data |
| // messages? At a higher level I'm thinking of ways to reduce the number |
| // of messages sent per flow. Currently, just creating a flow results in |
| // two messages - One where the initiator sends counters to the receiver |
| // and one where the receiver does the same. The first write does not |
| // block on receiving the counters because of the "steal from shared pool on |
| // first write" scheme, but still, sounds like too much traffic. |
| // (4) As an example of the above, consider the following code: |
| // vc.Connect().Close() |
| // This will result in 3 messages. But ideally it should involve 0. |
| // (5) Encryption of control messages to protect from network sniffers. |
