[FFmpeg-devel] [PATCH] ipv6-compatible resolve_host() replacement

Ronald S. Bultje rsbultje
Sun Sep 30 17:51:14 CEST 2007


Hi,

On 9/29/07, Michael Niedermayer <michaelni at gmx.at> wrote:
>
> On Sat, Sep 29, 2007 at 12:37:18PM -0400, Ronald S. Bultje wrote:
> > +void inetaddr_setport(AVInetAddr *addr, int port)
> > +{
> > +#ifdef CONFIG_IPV6
> > +    if (addr->family == AF_INET6)
> > +        ((struct sockaddr_in6 *) addr->addr)->sin6_port = htons(port);
> > +    else /* AF_INET */
> > +#endif
> > +        ((struct sockaddr_in *) addr->addr)->sin_port = htons(port);
> > +
> > +    addr->port = port;
> > +}
> > +
> > +AVInetAddr *inetaddr_alloc(int socket_stream)
> > +{
> > +    AVInetAddr *addr;
> > +    int extra_size;
> > +#ifdef CONFIG_IPV6
> > +    extra_size = sizeof(struct sockaddr_in6);
> > +#else
> > +    extra_size = sizeof(struct sockaddr_in);
> > +#endif
> > +    addr = av_malloc(sizeof(AVInetAddr) + extra_size);
> > +    addr->addr = (void *) &addr[1];
> > +    addr->addr_len = extra_size;
> > +    addr->next = NULL;
> > +    addr->family = addr->port = addr->protocol = 0;
> > +    addr->socket_type = socket_stream ? SOCK_STREAM : SOCK_DGRAM;
> > +
> > +    return addr;
> > +}
> > +
> > +void inetaddr_reparse(AVInetAddr *addr)
> > +{
> > +    addr->family = addr->addr->sa_family;
> > +#ifdef CONFIG_IPV6
> > +    if (addr->family == AF_INET6)
> > +        addr->port = ntohs(((struct sockaddr_in6 *)
> addr->addr)->sin6_port);
> > +    else
> > +#endif
> > +        addr->port = ntohs(((struct sockaddr_in *)
> addr->addr)->sin_port);
> > +}
>
> these functions are unused
> why are they here?


So, this is just the API that I need for ffserver and rtsp (see my other
email) to be simple to implement. Not all the API is actually used in this
patch. The use of each function is explained in the doxy comments. In short:

- _alloc() is to create an empty AVInetAddr that can be used in accept(fd,
addr->addr, &addr->addr_len); to subsequently have the address of the
connecting client in addr->addr.
- _reparse() should be called after accept() succeeds so that we can read
the port over which the connection is transferred, and the network family.
Now, this is not strictly needed, I'll admit that. If we wanted to, we could
use ntohs() and htons() on addr->addr with a macro to get to the struct
offset of the port without depending on 4/6-specific structs, it's not
impossible. Same for family. I just added this convenience API to get rid of
the multiple ntohs() and htons() conversions in ffserver.
- _set_port() is the opposite, for the same reason. This is used in ffserver
to set a new port on a per-elementary-stream multicast rtp connection to
clients, without having to create a new AVInetAddr struct.

_alloc() is needed. We could theoretically do w/o _reparse() and
_set_port(), they're more for convenience to make the calling code
(particularly ffserver) easier to read...

> +    const char *res;
> > +
> > +    if (addr->family != AF_INET)
> > +      return NULL;
> > +    else if (((struct sockaddr_in *) addr->addr)->sin_addr.s_addr ==
> INADDR_ANY) {
>
> please declare this with the proper struct, if needed with a union or
> whatever, these casts all over the code are ugly


I'll add a macro to access it at the proper struct offset, is that OK?
Unions are slightly inconvenient...

> + * @param port the port number that will be connected to.
> > + * @param passive 1 if the port will be used to bind() to, else 0.
> > + * @param socket_stream 1 if the returned address will be used for a
> > + *                      TCP/IP stream-based connection, 0 for others.
> > + * @param parse_only 1 if we should only parse numeric IPv4/6 host
> > + *                   addresses without resolving it using a name
> server.
>
> i think it would be more readable to use int flags here that is
>
> blah(0,1,1) is harder to read than blah(AV_RESOLVE_FOO|AV_RESOLVE_BAR)
> as the reader has too lookup what the argument 1,2,3 is to make sense of
> the
> first, while the name in the second makes it immedeatly clear


Sure, will do.

Ronald




More information about the ffmpeg-devel mailing list