Support for using multiple protocols #175
Conversation
balajiv113
force-pushed
the
multiple-conn
branch
from
ab1d2d8
to
ad1f66c
Compare
Signed-off-by: Balaji Vijayakumar <kuttibalaji.v6@gmail.com>
balajiv113
force-pushed
the
multiple-conn
branch
from
ad1f66c
to
8ab58e5
Compare
|
Does the API for use change? From the code I see that it internally handles this... right? |
|
Yes exactly no external API change its just the internal handling to support multiple protocol. The behaviour of protocol used in configuration alone will change now (now its used only in /connect mux) |
|
@cfergeau WDYT? |
| size := sProtocol.Buf() | ||
| sProtocol.Write(size, pkt.Size()) | ||
| return e.txBuf(pkt, size) | ||
| return e.txPkt(pkt) |
There was a problem hiding this comment.
For what it's worth, this would have been slightly more straightforward to review if there was a preliminary commit doing these tx() changes while keeping e.protocol (a Move stream socket handling in a txBuf() helper)
txPkt also does not seem very useful in a separate method as tx is a one liner, and the only user of this method.
These are just minor commets, this looks good, and worked fine with CRC, so ACK from me.
There was a problem hiding this comment.
Sure will keep this in mind for the next one 👍
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: balajiv113, cfergeau The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Just had more thoughts about this after digging into the code some more. I think only gvforwarder is making use of the /connect mux, and gvforwarder is using the HyperKit protocol. I suspect could be changed to hardcodetypes.HyperKitProtocol instead, and the Protocol field in types.Configuration would then become unused.
|
This support enables usage of multiple different protocols at the same time.
fixes #86
Compatibility
The code should be backward compatible. Just that now Accept methods like AcceptQemu, AcceptBess takes care of setting the protocol themself.
Even if the protocol mentioned in configuration is wrong, these Accept methods takes priority and sets proper one.
Note: The configuration still has Protocol and this is used for /connect mux.
Usecase
This will enable us to create a user-space network with multiple different hypervisors (eg: QEMU & VZ in macOS)