-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
HEP Max message length #9
Comments
good question :-) i think yes - otherwise you have to implement fragments. But can you please describe the scenario for such big duplication ? Normay we use payload protocols for miroring, but not entire transport frame. |
thanks for the fast reply, yes thats true but payload (e.g. HTTP2 body in Captured packet payload chunck) can grow and exceed the 65K which would cause the whole HEP message to overflow too or i am missing something ? |
honestly, and maybe I wrong, we don't expect SIGNALING protocols size over 65K. As I mentioned before, to duplicate HTTP2 Frames which size is over 65K, by using HEP is absolutely not efficient. First too much overhead (memcopy, serialization, deserialization), second too much traffic, third - too huge receiver buffer. IMHO better duplicate and store directly from network stack the packets as they arrived. But again, it's IMHO :-) |
valid point about the overhead and NW packets but the issue is that with HTTP2 comes the encryption so duplication/mirroring on this level is tricky. would you consider to increace the max size in a followup version ? |
@kinsu This is interesting. Could you expand on your usecase/project where this would be required? |
The intention is to use HEP to encapsulate HTTP2 for traffic monitoring. |
we can start working on HEP4 and increase the length field to 32 bytes (IMHO ~4G payload will be enougth) ;-) |
The beauty of HEP3 is its extensibility. We will shortly propose a backwards compatible extension for discussion. |
thank you i ll be waiting for the proposal- especially the backwards compatibility aspect |
By the way, are there any other changes that you have in mind as part of the HEP4 or just the field size that we were discussing above ? Also, do you have any (obviously rought) timeline on when the proposal will be available ? thanks again for the help! |
it probably take a week - we are now busy with cloud launch. Thank you! |
I personally doubt this change alone would be worth releasing HEP4.... |
thanks !
are there any other items that are requested/planned for HEP4 ? |
Hi ! are there any news on this topic ? thx |
Assuming that we want to use HEP to encapsulate an HTTP2 message (frame), max message size defined in HEP header (currently 65535) can be restrictive. i guess header change means new HEP version ?
The text was updated successfully, but these errors were encountered: