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, <sanjana.gupta...@gmail.com>
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, <sanjana....@gmail.com> 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, <sanjana....@gmail.com>
>>>> 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 protobuf+u...@googlegroups.com.
>>>>> To post to this group, send email to prot...@googlegroups.com.
>>>>> 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 protobuf+u...@googlegroups.com.
>>> To post to this group, send email to prot...@googlegroups.com.
>>> 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 protobuf+unsubscr...@googlegroups.com.
> To post to this group, send email to protobuf@googlegroups.com.
> 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 protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.

Reply via email to