Hi Saúl,
I have not thought this out completely, so it might not work. But here is
an global idea:
==Some types==
/* a typdef because interface indexes have different types on unix/windows
*/
typedef /*plaform dependent*/ uv_interface_idx_t;
/*a type to save the pkt info*/
typedef struct uv_udp_pkt_info
{
uv_interface_idx_t interface_index;
sa_family_t address_family;
union {
struct in_addr address_4;
struct in6_addr address_6;
} address;
} uv_udp_pkt_info_t;
==callback==
/*callback for uv_udp_recv_with_pkt_info_start()*/
void (*uv_udp_recv_with_pkt_info_cb)(uv_udp_t* handle, ssize_t nread, const
uv_buf_t* buf, const struct sockaddr* addr, const uv_udp_pkt_info_t*
pkt_info, unsigned flags);
==functions ==
/*same as uv_udp_send but with the packet_info received from
uv_udp_recv_with_pkt_info_cb*/
int uv_udp_send_with_pkt_info(uv_udp_send_t* req, uv_udp_t* handle, const
uv_buf_t bufs[], unsigned int nbufs, const struct sockaddr* addr, const
uv_udp_pkt_info_t* pkt_info, uv_udp_send_cb send_cb);
/*same as uv_udp_try_send but with the packet_info received from
uv_udp_recv_with_pkt_info_cb*/
int uv_udp_try_send_with_pkt_info(uv_udp_t* handle, const uv_buf_t bufs[],
unsigned int nbufs, const struct sockaddr* addr, const uv_udp_pkt_info_t*
pkt_info)
/*same as uv_udp_recv_start but with a different callback type. Only one of
uv_udp_recv_start / uv_udp_recv_with_pkt_info_start can be started */
int uv_udp_recv_with_pkt_info_start(uv_udp_t* handle, uv_alloc_cb alloc_cb,
uv_udp_recv_cb recv_with_pkt_info_cb)
uv_udp_try_send and uv_udp_recv_start can be mixed with
uv_udp_try_send_with_pkt_info uv_udp_recv_with_pkt_info_start
On windows XP if we were to support that, the uv_udp_recv_with_pkt_info_cb
callback would return null for pkt_info and accept null for
uv_udp_try_send_with_pkt_info / uv_udp_send_with_pkt_info.
As an alternative we could put the "const struct sockaddr* addr" of the
send and recv functions into the uv_udp_pkt_info struct.
Alternative nr 2: we could replace the current udp start_recv and
(try_)send completely with these new signatures
Regards,
Niels Werensteijn
Op donderdag 3 september 2015 09:29:17 UTC+2 schreef Saúl Ibarra Corretgé:
>
> Hi Niels,
>
> On 09/02/2015 03:15 PM, Niels Werensteijn wrote:
> > Hi,
> >
> > I am evaluating libuv for future use. We currently have an UDP based
> > protocol which has an issue on multi-homed machines. Packets that we
> > send back to clients always have the ip src address of the default
> > interface. When we bind the UDP socket to ANY (0.0.0.0 / ::0) this
> > causes the clients to drop our reply packets when they send their
> > packets to the ip of the *non*-default interface, since they originate
> > from a different ip address.
> >
> > This issue can be solved by setting the IP_PKTINFO / IP6_PKTINFO options
> > on the socket and using (WSA)recvmsg and (WSA)sendmsg to get the
> > receiving ip+interface or to specify it.
> >
> > My Question is if there is interest in supporting this in libuv. If so,
> > I could probably make a patch. One issue would be that this would not be
> > supported on win xp. (AFAIK WSARecvMsg /WSASendMsg are only supported in
> > Vista and up).
> >
>
> We kind of committed to keep the status quo for the v1.x series, that
> is, XP support included, but we'll drop it afterwards.
>
> Can you come up with a (as detailed as possible) API proposal? That way
> we can see if this would fit into v1.x or land in master and be part of
> v2.x, in which case there is no need to worry about Windows XP.
>
>
> Regards,
>
> --
> Saúl Ibarra Corretgé
> bettercallsaghul.com
>
>
>
--
You received this message because you are subscribed to the Google Groups
"libuv" 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 http://groups.google.com/group/libuv.
For more options, visit https://groups.google.com/d/optout.
