[Mpvdapi] 回复： MIF API Design Team

[Dapeng Liu <[e-mail]>]

在 2015年7月6日 星期一，下午3:04，Hui Deng 写道：
> Hi Dapeng
>   
> At this moment, we would expect that Erik could lead this MIF MPVD API design tem, please try to contribute the design team work from your draft.
> thanks a lot for your cooperation

Hi Hui,  

Sure.  
The draft is used used for the design team’s reference since it has some similarity with what Eric proposed in the list.  

Thanks,
Dapeng Liu

>   
> Best regards,
>   
> DENG Hui
>  
>   
> Date: Mon, 6 Jul 2015 14:25:12 +0800
> From: [e-mail] (mailto:[e-mail])
> To: [e-mail] (mailto:[e-mail])
> CC: [e-mail] (mailto:[e-mail]); [e-mail] (mailto:[e-mail]); [e-mail] (mailto:[e-mail]); [e-mail] (mailto:[e-mail]); [e-mail] (mailto:[e-mail])
> Subject: 回复： [Mpvdapi] MIF API Design Team
>  
> The updated version: https://tools.ietf.org/html/draft-liu-mif-socket-api-00  
>  
> --  
> Dapeng Liu
>  
>  
> 在 2015年7月5日 星期日，下午6:53，Dapeng Liu 写道：
>  
> > Hi Hui and Erik,  
> >  
> > Attachment is the draft I mentioned during the discussion. It was written before the Dallas meeting and it may not reflect the latest consensus we have.  
> >  
> > I am trying to update it.  
> >  
> >  
> >  
> > --  
> > Dapeng Liu
> >  
> >  
> > 在 2015年7月5日 星期日，下午3:27，Hui Deng 写道：
> >  
> > > Hi Erik
> > >   
> > > I guess that everbody is busy with deadline,
> > > could you kindly help to write down a draft about this proposal and then present it during coming MIF sesson,  
> > > then we get more people to review on how Android implement this.
> > >   
> > > Thanks a lot for your kind work
> > > Best regards,
> > >   
> > > DENG Hui
> > >  
> > >   
> > > > From: [e-mail] (mailto:[e-mail])
> > > > Date: Mon, 15 Jun 2015 19:55:15 +0900
> > > > Subject: Re: MIF API Design Team
> > > > To: [e-mail] (mailto:[e-mail])
> > > > CC: [e-mail] (mailto:[e-mail]); [e-mail] (mailto:[e-mail]); [e-mail] (mailto:[e-mail])
> > > >  
> > > > Sorry about that: it's back to back 3GPP and now Android release issues.
> > > >  
> > > > I spent the weekend reworking some notes on the things I described in
> > > > Dallas. That's not coming together quickly enough so let me lay
> > > > everything out here instead. In so doing I will try to describe more
> > > > about the approach Android took to see if people even think it makes
> > > > sense.
> > > >  
> > > > Let's assume for the sake of argument that C API definitions are
> > > > nicely isolated, maybe in some #include <netpvd.h> header file.
> > > >  
> > > > [1] Provisioning domains are represented by a "handle" kind of class,
> > > > android.net.Network:
> > > >  
> > > > https://developer.android.com/reference/android/net/Network.html
> > > >  
> > > > These are essentially handles to identify instances of attaches to
> > > > provisioning domains. The underlying identifier values are not
> > > > recycled (except after a really long time). Multiple temporally
> > > > disparate attaches to the same network each get a new instance
> > > > value--we have not yet found it of value to try to de-duplicate
> > > > attaches. Applications that want to know if you're attached to
> > > > "Starbucks" so they can startup and auto-sign-in use the relevant
> > > > handle value to query parameters (like SSID).
> > > >  
> > > > I would propose that a C API would have something like
> > > >  
> > > > typedef uint64_t pvd_handle_t
> > > > #define PVD_HANDLE_UNSPEC ((pvd_handle_t)0)
> > > >  
> > > > [2] Once an application has received a Network handle [let's save how
> > > > that happens for later] it can request that certain operations be
> > > > performed specifically within the associated PVD. Currently these
> > > > operations include:
> > > >  
> > > > [bind a file descriptor to a PVD to force packets to be sent using
> > > > the PVD's routing table]
> > > > android.net.Network#bindSocket()
> > > > https://developer.android.com/reference/android/net/Network.html#bindSocket(java.net.Socket (https://developer.android.com/reference/android/net/Network.html#bindSocket%28java.net.Socket))
> > > >  
> > > > [perform DNS lookups using a PVD's DNS servers]
> > > > android.net.Network#getAllByName()
> > > > https://developer.android.com/reference/android/net/Network.html#getAllByName(java.lang.String (https://developer.android.com/reference/android/net/Network.html#getAllByName%28java.lang.String))
> > > >  
> > > > [set the PVD for all file descriptors and DNS lookups for a
> > > > process, unless otherwise overridden]
> > > > android.net.ConnectivityManager#setProcessDefaultNetwork()
> > > > https://developer.android.com/reference/android/net/ConnectivityManager.html#setProcessDefaultNetwork(android.net.Network (https://developer.android.com/reference/android/net/ConnectivityManager.html#setProcessDefaultNetwork%28android.net.Network))
> > > >  
> > > > I would propose that a C API have at least the following:
> > > >  
> > > > [a] get/setsockopt(int fd, SOL_SOCKET, SO_PVD_HANDLE, &pvd_handle_t);
> > > > [b] getaddrinfo/getnameinfo some taking a pvd_handle_t
> > > > [c] discussion of recvmsg/sendmsg/accept semantics
> > > >  
> > > > Note that the last is particularly tricky. Operating systems need to
> > > > know how to "mark" incoming packets that would cause a new connection
> > > > such that they have the correct pvd_handle_t associated. This has
> > > > lots of impact on suitable address selection as well.
> > > >  
> > > > The C API should also have at least the following:
> > > >  
> > > > [d] system, process, and per-thread pvd_handle get/set calls
> > > >  
> > > > // These values are used by PVD-aware function calls when a PVD index
> > > > // is not explicitly specified.
> > > > pvd_handle_t pvd_system_default();
> > > >  
> > > > // Same as above, but operates at a per-process level. If no
> > > > // process-specific default has been set this MUST return the value
> > > > // of a call to pvd_system_default().
> > > > pvd_handle_t pvd_process_default();
> > > >  
> > > > // Same as above, but operates at a per-thread level. If no
> > > > // thread-specific default has been set this MUST return the value
> > > > // of a call to pvd_current_process_default().
> > > > pvd_handle_t pvd_thread_default();
> > > >  
> > > > int pvd_set_system_default(pvd_handle_t); // 0 or -1 && errno = EFOO
> > > > int pvd_set_process_default(pvd_handle_t); // 0 or -1 && errno = EFOO
> > > > int pvd_set_thread_default(pvd_handle_t); // 0 or -1 && errno = EFOO
> > > >  
> > > > [e] good discussion of a variety of EFOO errno return values.
> > > >  
> > > > When a PVD has gone away (e.g. we disconnected from WIFI), subsequent
> > > > operations on the associated pvd_handle should fail with errno =
> > > > ENONET.
> > > >  
> > > > [f] good discussion of how the process and thread default values
> > > > behave across fork/exec
> > > >  
> > > > FWIW, Android uses all of the above when NetworkMonitor is validating
> > > > a network--it does DNS lookups within the PVD, makes pvd-bound sockets
> > > > used for HTTP Direct or Proxy connections to check connectivity to a
> > > > URL:
> > > >  
> > > > https://android.googlesource.com/platform/frameworks/base/+/master/services/core/java/com/android/server/connectivity/NetworkMonitor.java
> > > >  
> > > > [3] the device has to build up configuration data continuously over
> > > > time, as DHCP results come back, and RAs come in bringing new prefixes
> > > > or new DNS servers.
> > > >  
> > > > Not that it's relevant, but Android accumulates these in an
> > > > android.net.LinkProperties object:
> > > >  
> > > > https://developer.android.com/reference/android/net/LinkProperties.html
> > > >  
> > > > as we currently only support a 1:1 mapping of PVDs to physical interfaces.
> > > >  
> > > > The means by which the operating system allocates pvd_handles, gathers
> > > > this data and associates it with a pvd_handle (including marking
> > > > incoming packets that would causes a new connection) might best be
> > > > left for a separate document, since sections 1 and 2 and background
> > > > theory will require a fair amount of text.
> > > >  
> > > > [4] Android lets processes register callbacks to be called when
> > > > certain network properties change, or when a new network shows up, or
> > > > one goes away. This is how applications receive the handles (Network
> > > > objects).
> > > >  
> > > > The UNIX way of doing these sorts of things...well, frequently leaves
> > > > much to be desired...but we should support multiple event-driven
> > > > models, I think.
> > > >  
> > > > [5] we'll want an API for an application to pass in a handle and get
> > > > an ever expanding list of parameters (expanding as we think to add
> > > > them and write documents about them).
> > > >  
> > > > The Android ConnectivityManager mitigates all this stuff and passes
> > > > around NetworkInfo objects which encapsulate extra information like
> > > > SSIDs, whether the Network is Ethernet, Mobile, Wi-Fi, or whether it's
> > > > metered, and so on.
> > > >  
> > > > The closest UNIX-style analogy here would be some interface that is
> > > > getsockopt()-like, I think. Something like:
> > > >  
> > > > int pvd_get_attribute(pvd_handle_t, PVD_ATTR_(HWTYPE|METERED|...),
> > > > void *returned_blob);
> > > >  
> > > > And then it will be possible for code to be written like
> > > >  
> > > > #ifdef PVD_ATTR_HTTP_PROXY_URL
> > > >  
> > > > char proxyString[PVD_ATTR_HTTP_PROXY_URL_MAXLEN];
> > > > memset(proxyString, 0, sizeof(proxyString));
> > > > if (!pvg_get_attribute(pvd_handle, PVD_ATTR_HTTP_PROXY_URL, proxyString)) {
> > > > perror("Sadness!");
> > > > return -1;
> > > > }
> > > >  
> > > > #endif
> > > >  
> > > >  
> > > > ---
> > > >  
> > > > That's a massive brain dump, and I apologize for it and also that it's so late.
> > > >  
> > > > Let me know what y'all think.
> > > > -Erik
> > > >  
> > > > On Mon, Jun 8, 2015 at 11:18 PM, Hui Deng <[e-mail] (mailto:[e-mail])> wrote:
> > > > > Hi Erik
> > > > >
> > > > > We are waiting for your lead to start this work asap. Feel free to us know
> > > > > when you are ready.
> > > > >
> > > > > Hi Ian, thanks a lot for letting us know that you are going to work with a
> > > > > university on the implementations.
> > > > > Erik was quite busy for 3GPP SA2 work recently, we are waiting for his
> > > > > return to lead the work.
> > > > >
> > > > > Best regards,
> > > > >
> > > > > DENG Hui
> > > > >
> > > > >
> > > > >> From: [e-mail] (mailto:[e-mail])
> > > > >> Subject: MIF API Design Team
> > > > >> Date: Mon, 8 Jun 2015 14:07:02 +0200
> > > > >> CC: [e-mail] (mailto:[e-mail])
> > > > >> To: [e-mail] (mailto:[e-mail])
> > > > >>
> > > > >> Hi Hui,
> > > > >>
> > > > >> My apologies for not being in contact sooner. Things don’t always move as
> > > > >> quickly as hoped around here!
> > > > >>
> > > > >> The current status is that we have provisionally obtained the necessary
> > > > >> resources to start working on a proof of concept implementation of the MIF
> > > > >> architecture. We will be doing this in partnership with a University.
> > > > >>
> > > > >> Tomorrow (9th July) we will start the scoping work with the implementor.
> > > > >> What I want to come out of this work is a proof of concept implementation of
> > > > >> the MIF architecture on a ‘generic’ Linux based platform. As Eric is working
> > > > >> on an Android implementation for the mobile use case, I think that this
> > > > >> should complement his work quite well and serve to provide some good
> > > > >> implementation experience which can be fed back into the update of the MIF
> > > > >> API document.
> > > > >>
> > > > >> I’ve sent a subscription request to the MIF API design team mailing list.
> > > > >> Once we’ve got some firmer details agreed with the implementors, I’ll make
> > > > >> an announcement on the m/l of what we’re doing and we can discuss what the
> > > > >> best way of aligning the two implementation efforts.
> > > > >>
> > > > >> Best regards,
> > > > >> Ian
> > > _______________________________________________
> > > Mpvdapi mailing list
> > > [e-mail] (mailto:[e-mail])
> > > https://www.ietf.org/mailman/listinfo/mpvdapi
> > >  
> > >  
> > >  
> >  
> >  
> >  
> > 附件：  
> > - draft-liu-mif-socket-api-00.txt
> >  
>  
>