[jira] [Commented] (MESOS-1919) Create IP address abstraction
[
https://issues.apache.org/jira/browse/MESOS-1919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14225384#comment-14225384
]
Evelina Dumitrescu commented on MESOS-1919:
---
What I have tried so far is to write the struct IPAddress to work with the IPv4
part and integrate it in the code. Further, I want to extend it to IPv6 and
also add IPv6 functionalities in the code(ipv6 fields in protobuffers,
LIBPROCESS_IPV6 environment variable, make libprocess instances in
process:initialize bind on an IPv6 socket). I want to use the IP class be used
only for parsing - converting from different representations of
address/netmask(eg: "string representation of address/netmask or address and
netmask prefix) to the Mesos internal one(stored in IPAddress).
So, the problems that I want to address are:
Environment variables and libprocess
I think that each instance of libprocess should use both IPv4 and IPv6 address
for binding on(eg process::initialize). This means creating an additional
environment variable LIBPROCESS_IPv6 and let the endpoint that wants to connect
to decide which INET family to use.
Instead of environment variables, why don't we use IPC (shared memory, message
queue) ?
MasterInfo protobuffers
The MasterInfo protobuffers should modify accordingly - a master protobuffer
should have both an ipv4 and an ipv6 field (maybe mark both as optional, but
make sure that at least one of them is set)
Libnl
Use the current create and remove methods also for IPv6 addresses.
Use the same Classifiers, but write different encode/decode functions for
IPv4/ICMP and IPv6/ICMPv6 because the headers differ.
In encodeFilter/decodeFilter, depending on the family of the destinationIP
from the Classifier the encode/decode function for IP/IPv6 shoudl be called
eg: The PortMappingIsolatorProcess class uses a static method create that
returns an instance of the class. The hostIP is passed as a parameter to the
constructor
Result hostIP = net::ip(eth0.get());
The net::ip method returns the first ip address from the eth0 interface. I
want to add a parameter to the ip method specifing the family type to be
returned.
Result hostIP = net::ip(eth0.get(), AF_INET);
Result hostIPv6 = net::ip(eth0.get(), AF_INET6);
In the addHostIPFilters
Try vethToHostLoPublic = filter::ip::create(
veth,
ingress::HANDLE,
ip::Classifier(None(), net::IP(hostIP.address().ipv4_addr.s_addr), range,
None()),
Priority(IP_FILTER_PRIORITY, NORMAL),
action::Redirect(lo));
Replace obsolete functions and define methods in IPAddress to make callsites
AF-independent
Replace functions like gethostbyname with getaddrinfo, I will add such method
in IPAddress because the call for getaddrinfo is inet-dependant, to avoid
situations like
while ((result = gethostbyname2_r(
host.c_str(), AF_INET, &he, temp, length, &hep, &herrno)) == ERANGE) {
...
}
node.ip.ipv4_addr = *((struct in_addr*) hep->h_addr_list[0]);
Master ID
How is going to be defined the master ID if the master is going to have both
IPV4 and IPv6 addresses?
// The master ID is currently comprised of the current date, the IP
// address and port from self() and the OS PID.
Try id =
strings::format("%s-%u-%u-%d", DateUtils::currentDate(),
self().node.ip, self().node.port, getpid());
> Create IP address abstraction
> -
>
> Key: MESOS-1919
> URL: https://issues.apache.org/jira/browse/MESOS-1919
> Project: Mesos
> Issue Type: Task
> Components: libprocess
>Reporter: Dominic Hamon
>Assignee: Evelina Dumitrescu
>Priority: Minor
>
> in the code many functions need only the ip address to be passed as a
> parameter. I don't think it would be desirable to use a struct
> SockaddrStorage (MESOS-1916).
> Consider using a {{std::vector}} (see {{typedef
> std::vector IPAddressNumber;}} in the Chromium project)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-1919) Create IP address abstraction
[
https://issues.apache.org/jira/browse/MESOS-1919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14222703#comment-14222703
]
Evelina Dumitrescu commented on MESOS-1919:
---
Because this is a more involved change, I thought it would be a good idea to
submit a draft with the temporary progress of the task and receive feedback as
soon as possible.
https://reviews.apache.org/r/28386/
https://reviews.apache.org/r/28387/
https://reviews.apache.org/r/28388/
> Create IP address abstraction
> -
>
> Key: MESOS-1919
> URL: https://issues.apache.org/jira/browse/MESOS-1919
> Project: Mesos
> Issue Type: Task
> Components: libprocess
>Reporter: Dominic Hamon
>Assignee: Evelina Dumitrescu
>Priority: Minor
>
> in the code many functions need only the ip address to be passed as a
> parameter. I don't think it would be desirable to use a struct
> SockaddrStorage (MESOS-1916).
> Consider using a {{std::vector}} (see {{typedef
> std::vector IPAddressNumber;}} in the Chromium project)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-1919) Create IP address abstraction
[
https://issues.apache.org/jira/browse/MESOS-1919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14205097#comment-14205097
]
Dominic Hamon commented on MESOS-1919:
--
I think trying to bind on both seems reasonable. The abstraction for connecting
should also try both, probably using [happy
eyeballs|http://en.wikipedia.org/wiki/Happy_Eyeballs].
libprocess should almost certainly be extended to use a socket address instead
of uint32_t _ip_ to store it.
> Create IP address abstraction
> -
>
> Key: MESOS-1919
> URL: https://issues.apache.org/jira/browse/MESOS-1919
> Project: Mesos
> Issue Type: Task
> Components: libprocess
>Reporter: Dominic Hamon
>Assignee: Evelina Dumitrescu
>Priority: Minor
>
> in the code many functions need only the ip address to be passed as a
> parameter. I don't think it would be desirable to use a struct
> SockaddrStorage (MESOS-1916).
> Consider using a {{std::vector}} (see {{typedef
> std::vector IPAddressNumber;}} in the Chromium project)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-1919) Create IP address abstraction
[
https://issues.apache.org/jira/browse/MESOS-1919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14203272#comment-14203272
]
Evelina Dumitrescu commented on MESOS-1919:
---
How is it going to be decided the family type for libprocess and mesos?
Currently, in libporcess the default __ip__ is set to 0:
static uint32_t __ip__ = 0;
Should we set the default ip to AF_INET and 0.0.0.0 ?
Should we allow binding on both IPv6 and IPv4 addresses(and make sure that at
least one of them is defined) and let the other endpoint decide which protocol
to use to connect?
This envolves to define another environment variable, LIBPROCESS_IPV6. If this
variables are not defined, when we look for the public IP address call
gethostbyname2 for both AF_INET/AF_INET6?
In this case, which values to store in __ip__ (libprocess has a single variable
to store the IP)?
Otherwise, if we use only one type of protocol family we have to tell
libprocess which type to use, ie by defining an additional environment variable
LIBPROCESS_INET_ FAMILY .
The same thing happends also to mesos in port_mapping. If we decide to use only
a single family type, should we pass a flag to this module?
> Create IP address abstraction
> -
>
> Key: MESOS-1919
> URL: https://issues.apache.org/jira/browse/MESOS-1919
> Project: Mesos
> Issue Type: Task
> Components: libprocess
>Reporter: Dominic Hamon
>Assignee: Evelina Dumitrescu
>Priority: Minor
>
> in the code many functions need only the ip address to be passed as a
> parameter. I don't think it would be desirable to use a struct
> SockaddrStorage (MESOS-1916).
> Consider using a {{std::vector}} (see {{typedef
> std::vector IPAddressNumber;}} in the Chromium project)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-1919) Create IP address abstraction
[
https://issues.apache.org/jira/browse/MESOS-1919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14196970#comment-14196970
]
Cong Wang commented on MESOS-1919:
--
I don't think we need to worry about u32 filters for IPv4, because they never
work for IPv6 (IPv6 packets are just ignored), nor it makes much sense to do
port range based routing for IPv6. We should really use one IP address per
container solution when using IPv6.
> Create IP address abstraction
> -
>
> Key: MESOS-1919
> URL: https://issues.apache.org/jira/browse/MESOS-1919
> Project: Mesos
> Issue Type: Task
> Components: libprocess
>Reporter: Dominic Hamon
>Assignee: Evelina Dumitrescu
>Priority: Minor
>
> in the code many functions need only the ip address to be passed as a
> parameter. I don't think it would be desirable to use a struct
> SockaddrStorage (MESOS-1916).
> Consider using a {{std::vector}} (see {{typedef
> std::vector IPAddressNumber;}} in the Chromium project)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-1919) Create IP address abstraction
[
https://issues.apache.org/jira/browse/MESOS-1919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14184789#comment-14184789
]
Evelina Dumitrescu commented on MESOS-1919:
---
Possible cases where it wouldn't make sense to use
sockaddr_in/sockaddr_in6/sockaddr_storage:
- the IP class and the various situations where it is used:
- libnl Classifiers for ICMP
- libnl routing Rule class
- for getting IPs from interfaces (ie: inline Result ip(const
std::string& name))
- Process class - separate methods for getting the ip and port(ie: used in
./src/master/http.cpp, type_utils.cpp, sched.cpp)
- flags and environment variables setting.
The IP abstraction will be used also for the netmask.
I think that the Node class should be left as it is.
IMO, Node actually abstracts the endpoint notion: it defines the association of
the ip & port for a connetion.
A node defines more the host(which can have multiple active endpoints).
I want to propose to rename this class in Endpoint and also replace the ip and
port fields from UPID class with this type.
All the IPv6/IPv4 abstraction should be moved into a single class.
This class should be able to work with the SockaddrStorage struct (that will be
useful for the functions that use sockaddr) and with the IPAddress struct(that
will be useful for the situations where only the IP is needed). So far, I have
reffered to this class as IPEndPoint, but the class name should be changed to
something more appropiate: maybe InetHandler(because it handles the
SockaddrStorage and IPAddress structs).
> Create IP address abstraction
> -
>
> Key: MESOS-1919
> URL: https://issues.apache.org/jira/browse/MESOS-1919
> Project: Mesos
> Issue Type: Task
> Components: libprocess
>Reporter: Dominic Hamon
>Assignee: Evelina Dumitrescu
>Priority: Minor
>
> in the code many functions need only the ip address to be passed as a
> parameter. I don't think it would be desirable to use a struct
> SockaddrStorage (MESOS-1916).
> Consider using a {{std::vector}} (see {{typedef
> std::vector IPAddressNumber;}} in the Chromium project)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-1919) Create IP address abstraction
[
https://issues.apache.org/jira/browse/MESOS-1919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14184405#comment-14184405
]
Michael Park commented on MESOS-1919:
-
Just noticed that this ticket is specifically for providing an abstraction for
IP address only. Is there motivation behind this aside from "to pass around
less data"? I can't seem a good reason to introduce an abstraction for IP
address only. IMHO, we should just provide an abstraction for *node*.
> Create IP address abstraction
> -
>
> Key: MESOS-1919
> URL: https://issues.apache.org/jira/browse/MESOS-1919
> Project: Mesos
> Issue Type: Task
> Components: libprocess
>Reporter: Dominic Hamon
>Assignee: Evelina Dumitrescu
>Priority: Minor
>
> in the code many functions need only the ip address to be passed as a
> parameter. I don't think it would be desirable to use a struct
> SockaddrStorage (MESOS-1916).
> Consider using a {{std::vector}} (see {{typedef
> std::vector IPAddressNumber;}} in the Chromium project)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-1919) Create IP address abstraction
[
https://issues.apache.org/jira/browse/MESOS-1919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14184331#comment-14184331
]
Michael Park commented on MESOS-1919:
-
I agree with [~jvanremoortere] that we should avoid the use of {{std::vector}}
and I'm in favor of the {{union}} approach. It looks to me like you're trying
to piece together an abstraction for IP address (based on the use of
{{in_addr}}) but I think it would make more sense to use {{sockaddr_in}} to
present a *node* instead, which encapsulates an IP address + port number. This
way we can leverage all of the functions that take {{sockaddr *}}.
Here's a sample implementation of it using the {{union}} approach. Implicit
conversion to {{sockaddr *}} is allowed for natural use with functions that
take {{sockaddr *}}, but of course we could make it explicit if we prefer. The
functions {{getAddress}} and {{getPort}} are shown for example purposes.
{code:title=node.h|borderStyle=solid}
class Node {
public:
explicit Node(uint16_t family, uint16_t port, const char *address) :
storage() {
storage.ss_family = family;
int result;
switch (storage.ss_family) {
case AF_INET: {
ipv4.sin_port = htons(port);
result = inet_pton(storage.ss_family, address, &ipv4.sin_addr);
break;
} // case
case AF_INET6: {
ipv6.sin6_port = htons(port);
result = inet_pton(storage.ss_family, address, &ipv6.sin6_addr);
break;
} // case
} // switch
if (result < 0) {
// Error: system
} else if (result == 0) {
// Error: parse
}
}
// ...
operator const sockaddr *() const { return &generic; }
operator sockaddr *() { return &generic; }
std::string getAddress() const {
std::string result;
switch (storage.ss_family) {
case AF_INET: {
char buffer[INET_ADDRSTRLEN];
if (inet_ntop(storage.ss_family, &ipv4.sin_addr, buffer,
sizeof(buffer)) == NULL) {
// Error
}
result = buffer;
break;
}
case AF_INET6: {
char buffer[INET6_ADDRSTRLEN];
if (inet_ntop(storage.ss_family, &ipv6.sin6_addr, buffer,
sizeof(buffer)) == NULL) {
// Error
}
result = buffer;
break;
}
}
return result;
}
uint16_t getPort() const {
uint16_t result;
switch (storage.ss_family) {
case AF_INET: {
result = ipv4.sin_port;
break;
}
case AF_INET6: {
result = ipv6.sin6_port;
break;
}
}
return ntohs(result);
}
private:
union {
sockaddr_storage storage;
sockaddr_in ipv4;
sockaddr_in6 ipv6;
sockaddr generic;
};
};
{code}
> Create IP address abstraction
> -
>
> Key: MESOS-1919
> URL: https://issues.apache.org/jira/browse/MESOS-1919
> Project: Mesos
> Issue Type: Task
> Components: libprocess
>Reporter: Dominic Hamon
>Assignee: Evelina Dumitrescu
>Priority: Minor
>
> in the code many functions need only the ip address to be passed as a
> parameter. I don't think it would be desirable to use a struct
> SockaddrStorage (MESOS-1916).
> Consider using a {{std::vector}} (see {{typedef
> std::vector IPAddressNumber;}} in the Chromium project)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-1919) Create IP address abstraction
[
https://issues.apache.org/jira/browse/MESOS-1919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14184139#comment-14184139
]
Joris Van Remoortere commented on MESOS-1919:
-
[~evelinad] My comment about using an stl container was not about allocating
too much memory. It was about:
1. Using dynamic allocation rather than local storage. Dynamic allocation has a
higher run-time cost and can trigger locking of the heap (depending on the
allocator). Since we know these types are fixed size and small, we can allocate
them directly in the managing object like you did in the union example.
2. STL containers are primarily designed to deal with collections of objects
that are dynamic (change in size over time, or the size it not known till
runtime). When we are trying to represent a very specific behavior that
requires a specific amount of storage then we should use a type (such as your
example struct) to more accurately represent the idea.
If you run valgrind and look at the allocation count of the following 2
examples it will be more clear:
{code:title=a.cc|borderStyle=solid}
#include
#include
struct IP {
IP() : data{1,2,3,4,5,6,7,8} {}
std::vector data;
};
int main() {
IP a;
return 0;
}
{code}
{code:title=valgrind ./a.out|borderStyle=solid}
total heap usage: 1 allocs, 1 frees, 8 bytes allocated
{code}
{code:title=b.cc|borderStyle=solid}
#include
#include
struct IP2 {
IP2(int64_t val) : dataBig(val) {}
IP2(int8_t val) : dataSmall(val) {}
union {
int64_t dataBig;
int8_t dataSmall;
};
};
int main() {
int8_t i8 = 3;
int64_t i64 = -1;
IP2 a(i8);
IP2 b(i8);
return 0;
}
{code}
{code:title=valgrind ./b.out|borderStyle=solid}
total heap usage: 0 allocs, 0 frees, 0 bytes allocated
{code}
> Create IP address abstraction
> -
>
> Key: MESOS-1919
> URL: https://issues.apache.org/jira/browse/MESOS-1919
> Project: Mesos
> Issue Type: Task
> Components: libprocess
>Reporter: Dominic Hamon
>Assignee: Evelina Dumitrescu
>Priority: Minor
>
> in the code many functions need only the ip address to be passed as a
> parameter. I don't think it would be desirable to use a struct
> SockaddrStorage (MESOS-1916).
> Consider using a {{std::vector}} (see {{typedef
> std::vector IPAddressNumber;}} in the Chromium project)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-1919) Create IP address abstraction
[
https://issues.apache.org/jira/browse/MESOS-1919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14183709#comment-14183709
]
Evelina Dumitrescu commented on MESOS-1919:
---
[~jmlvanre] Your concern on using the stl vector representation was that the
stl vector will alocate more memory than is needed.
The stl vector initial capacity starts from 0(for the default constructor) and
doubles the allocated memory when reallocation is needed. And for the
particular case of the IPV4 and IPv6 sizes(which have the form of power of two)
memory will not be allocated and then left unused.
> Create IP address abstraction
> -
>
> Key: MESOS-1919
> URL: https://issues.apache.org/jira/browse/MESOS-1919
> Project: Mesos
> Issue Type: Task
> Components: libprocess
>Reporter: Dominic Hamon
>Assignee: Evelina Dumitrescu
>Priority: Minor
>
> in the code many functions need only the ip address to be passed as a
> parameter. I don't think it would be desirable to use a struct
> SockaddrStorage (MESOS-1916).
> Consider using a {{std::vector}} (see {{typedef
> std::vector IPAddressNumber;}} in the Chromium project)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-1919) Create IP address abstraction
[
https://issues.apache.org/jira/browse/MESOS-1919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14183690#comment-14183690
]
Evelina Dumitrescu commented on MESOS-1919:
---
I wanted to use struct IPAddress only for storage and create all the abstaction
needed in the IPEndPoint class and the callsites will use only the metods from
the IPEndPoint class. It might be better to use this representation because the
networking calls(ie inet_ntop, inet_pton) work with in_addr and in6_addr
structs. Otherwise, we need to convert the vector to this type of structs each
time.
> Create IP address abstraction
> -
>
> Key: MESOS-1919
> URL: https://issues.apache.org/jira/browse/MESOS-1919
> Project: Mesos
> Issue Type: Task
> Components: libprocess
>Reporter: Dominic Hamon
>Assignee: Evelina Dumitrescu
>Priority: Minor
>
> in the code many functions need only the ip address to be passed as a
> parameter. I don't think it would be desirable to use a struct
> SockaddrStorage (MESOS-1916).
> Consider using a {{std::vector}} (see {{typedef
> std::vector IPAddressNumber;}} in the Chromium project)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-1919) Create IP address abstraction
[
https://issues.apache.org/jira/browse/MESOS-1919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14183537#comment-14183537
]
Dominic Hamon commented on MESOS-1919:
--
this requires every callsite to check the family and get the right address,
which is not the point of an abstraction. This may be ok for storage, but I'd
rather the callsites interact with IP addresses without any notion of what
family is used.
> Create IP address abstraction
> -
>
> Key: MESOS-1919
> URL: https://issues.apache.org/jira/browse/MESOS-1919
> Project: Mesos
> Issue Type: Task
> Components: libprocess
>Reporter: Dominic Hamon
>Assignee: Evelina Dumitrescu
>Priority: Minor
>
> in the code many functions need only the ip address to be passed as a
> parameter. I don't think it would be desirable to use a struct
> SockaddrStorage (MESOS-1916).
> Consider using a {{std::vector}} (see {{typedef
> std::vector IPAddressNumber;}} in the Chromium project)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-1919) Create IP address abstraction
[
https://issues.apache.org/jira/browse/MESOS-1919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14183448#comment-14183448
]
Evelina Dumitrescu commented on MESOS-1919:
---
After serveral discussions, I have proposed the following structure:
struct IPAddress {
uint8_t family;
union {
struct in_addr ipv4_address;
struct in6_addr ipv6_address;
};
};
Is everybody okay to stick to this representation?
> Create IP address abstraction
> -
>
> Key: MESOS-1919
> URL: https://issues.apache.org/jira/browse/MESOS-1919
> Project: Mesos
> Issue Type: Task
> Components: libprocess
>Reporter: Dominic Hamon
>Assignee: Evelina Dumitrescu
>Priority: Minor
>
> in the code many functions need only the ip address to be passed as a
> parameter. I don't think it would be desirable to use a struct
> SockaddrStorage (MESOS-1916).
> Consider using a {{std::vector}} (see {{typedef
> std::vector IPAddressNumber;}} in the Chromium project)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-1919) Create IP address abstraction
[
https://issues.apache.org/jira/browse/MESOS-1919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14182028#comment-14182028
]
Dominic Hamon commented on MESOS-1919:
--
We need to support gcc-4.4 at least for now so the first option is out of
contention.
> Create IP address abstraction
> -
>
> Key: MESOS-1919
> URL: https://issues.apache.org/jira/browse/MESOS-1919
> Project: Mesos
> Issue Type: Task
> Components: libprocess
>Reporter: Dominic Hamon
>Assignee: Evelina Dumitrescu
>Priority: Minor
>
> in the code many functions need only the ip address to be passed as a
> parameter. I don't think it would be desirable to use a struct
> SockaddrStorage (MESOS-1916).
> Consider using a {{std::vector}} (see {{typedef
> std::vector IPAddressNumber;}} in the Chromium project)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-1919) Create IP address abstraction
[
https://issues.apache.org/jira/browse/MESOS-1919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14181986#comment-14181986
]
Evelina Dumitrescu commented on MESOS-1919:
---
So far have been proposed two ideas:
- __int128_t/__uint128_t types from gcc. Gcc supports this since the 4.6
release.
https://gcc.gnu.org/gcc-4.6/changes.html
- std::vector of unsigned char. If we choose this approach, we could know
easier the family type of the protocol by the size of the vector (eg: IPv4 will
have 4 bytes length, IPv6 will have 16).
Which of these options should we decide on ?
> Create IP address abstraction
> -
>
> Key: MESOS-1919
> URL: https://issues.apache.org/jira/browse/MESOS-1919
> Project: Mesos
> Issue Type: Task
> Components: libprocess
>Reporter: Dominic Hamon
>Assignee: Evelina Dumitrescu
>Priority: Minor
>
> in the code many functions need only the ip address to be passed as a
> parameter. I don't think it would be desirable to use a struct
> SockaddrStorage (MESOS-1916).
> Consider using a {{std::vector}} (see {{typedef
> std::vector IPAddressNumber;}} in the Chromium project)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
