I would be amazed if there isn't a way of getting the raw underlying bytes from the IP address, rather than the text (ASCII). The address 111.111.111.111 is literally the 4 bytes with decimal values 111, 111, 111 and 111. No ASCII required.
On Wed, 18 Jul 2018, 10:28 sanjana gupta, <[email protected]> wrote: > Hey Marc, > > I am sorry if I am repeating my words. Please enlighten me on this thing : > > "bytes" requires me to give a std::string (c++) value as input. The > problem with string for me is that a usual 4-byte ipv4 address like > 111.111.111.111 becomes 15-bytes string "111.111.111.111" > > Having said that, I feel discouraged to use bytes over uint32 (or int type > for that matter) as it already increases the *size of the data to be > encoded*. As a result, we can say that : > size of (encoded message using "bytes" type) > size of (encoded message > using "int" type) > > Is my understanding correct? Thanks! > > > On Wednesday, July 18, 2018 at 2:40:01 PM UTC+5:30, Marc Gravell wrote: >> >> At that point I'd probably use "repeated bytes", then. It'll cost you an >> extra byte on v4 addresses, but it is simple. >> >> On Wed, 18 Jul 2018, 09:36 sanjana gupta, <[email protected]> wrote: >> >>> Thanks Marc for your reply! By mistake I wrote 8-bytes for ipv4. I have >>> corrected it as 4-bytes in my question. Thanks for that :) >>> >>> One thing I want to ask you is that can I use "oneof" if my field >>> "localEndpoint" is repeated? >>> I mean to say that my one "profile" message can have any among : >>> -> 2 ipv4 addresses >>> -> OR 2 ipv6 addresses >>> -> OR 1 ipv4 + 1 ipv6 addresses >>> in the field "localEndpoint". >>> >>> So in that case, is "oneof" usage correct? I think that a "oneof" cannot >>> be repeated. Please correct me if I am wrong. >>> >>> On Wednesday, July 18, 2018 at 12:54:39 PM UTC+5:30, Marc Gravell wrote: >>>> >>>> You should be able to encode ipv4 in 4 bytes, making fixed32 ideal, >>>> since you can avoid the length prefix. For ipv6, you're going to need 16 >>>> bytes, so "bytes" is probably your best bet, since it will only require a >>>> single header. You can then create a union of those: >>>> >>>> oneof ip_addr { >>>> fixed32 v4 = 1; >>>> bytes v6 = 2; >>>> } >>>> >>>> That seems pretty optimal to me. >>>> >>>> Marc >>>> >>>> On Wed, 18 Jul 2018, 08:16 sanjana gupta, <[email protected]> >>>> wrote: >>>> >>>>> I read that protobuf has a type called "*bytes*" which can store >>>>> arbitrary number of bytes and is the equivalent of "C++ string". >>>>> >>>>> The reason why I don't prefer to use "bytes" is that it expects input >>>>> as a C++ string i.e., boost IP will need to be converted to a string. >>>>> >>>>> >>>>> Now my concern lies here : I want to perform serialize and send the >>>>> encoded protobuf message over TCP socket. I want to ensure that the >>>>> *encoded >>>>> message size is as small as possible*. >>>>> >>>>> >>>>> Currently, I am using the below .proto file : >>>>> >>>>> syntax = "proto2"; >>>>> >>>>> message profile >>>>> >>>>> { >>>>> >>>>> repeated *uint32* localEndpoint = 1; >>>>> >>>>> repeated *uint32* remoteEndpoint = 2; >>>>> >>>>> } >>>>> >>>>> >>>>> In order to save boost IP in the protobuf message, I am first >>>>> converting boost IP into byte-format array by using >>>>> "boost::asio::ip::address_v4::to_bytes()". So for a v4 IP, resultant array >>>>> size is 8. Then I am converting 1st 4 bytes from the resultant byte-array >>>>> into one uint32_t number and then storing in "localEndpoint" field of the >>>>> protobuf message. Likewise, I repeat for the next 4 bytes. I am taking 4 >>>>> bytes at a time so as to utilize full 32 bits of the uint32. >>>>> >>>>> >>>>> Hence for a v4 address, 2 occurrence of "localEndpoint" field is used. >>>>> Similarly, for a v6 address, 4 occurrence of "localEndpoint" field is >>>>> used. >>>>> >>>>> >>>>> Please allow me to highlight that if I had used "bytes" here, my input >>>>> string itself would have been of size 15 bytes for a v4 ip like >>>>> 111.111.111.111 >>>>> >>>>> >>>>> Using uint32 instead of "bytes" does save me some encoded-data-size >>>>> but I am looking for a more efficient protobuf type requiring lesser >>>>> number >>>>> of bytes. >>>>> >>>>> >>>>> Sorry for a long description but I wanted to explain my query in >>>>> details. Please help me.. Thanks a lot in advance :) >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "Protocol Buffers" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to [email protected]. >>>>> To post to this group, send email to [email protected]. >>>>> Visit this group at https://groups.google.com/group/protobuf. >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Protocol Buffers" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To post to this group, send email to [email protected]. >>> Visit this group at https://groups.google.com/group/protobuf. >>> For more options, visit https://groups.google.com/d/optout. >>> >> -- > You received this message because you are subscribed to the Google Groups > "Protocol Buffers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at https://groups.google.com/group/protobuf. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/protobuf. For more options, visit https://groups.google.com/d/optout.
