locked
Is MetroUI network API going to include IPv6 stateless address configuration?

    General discussion

  • Looking at http://msdn.microsoft.com/en-us/library/windows/apps/br205759(v=VS.85).aspx (Win32 and COM for Metro style apps (networking) ) I only see Dhcp... and Ws... calls. IPv6 does away with the need for DHCP and NAT (Network Address Translation) which have been the bane of distributed IPv4. IPv6's ability to do Stateless Address Autoconfiguration (SLAAC) means there is no need for ISPs to dole out (and charge for) IP addresses. Undoubtedly the telecoms will fight hard to keep this from happening (think $$$). But it would be a shame if Microsoft inadvertantly, with their new MetroUI platform, did the telecom's bidding by not implementing this feature of IPv6. Without SLAAC calls, MetroUI apps will not be able to natively participate in the new world of content-push distributed apps and as a result will be stuck in the browser era of the internet.

    What is needed is a set of calls like Slaac... (stateless address autoconfiguration). Without these calls, MetroUI apps will be limited to simplistic browsing and feeds like today's web apps. With such calls, each MetroUI app would be able to enter the new distributed non-cloud world of push content from mobile devices.

    The question: does MS have plans for implementing a SLAAC interface for MetroUI? If not, then could someone explain why not (other than the non-Steve-Jobsian "no one is asking for it").


    RT


    Thursday, October 27, 2011 4:18 PM

All replies

  • Hi RT,

    Thanks for taking the time to review the Win32 / COM API's exposed to Metro style apps. That list contains the current list of API's Metro style apps are allowed to call. They are not a full representation of what the underlying OS supports. The IPv6 stateless autoconfig if I'm understanding your inquiry correctly, has existed in the OS for sometime:

    http://technet.microsoft.com/en-us/magazine/2007.08.cableguy.aspx

     

    A Metro style app shouldn't need to concern itself with the lower level IP configuration. If you haven't had a chance to review them yet, there are a couple //build/ presentations on networking and sockets programming in Metro style apps:

     

    Creating connected apps that work on today's networks

    http://channel9.msdn.com/Events/BUILD/BUILD2011/PLAT-785T

    Building Windows runtime sockets apps (

    http://channel9.msdn.com/Events/BUILD/BUILD2011/PLAT-580T

    Note the HostName class discussed in this sockets talk at ~22min into the video as this may address some of your needs.

     

    If there is a scenario you feel should be available for a Metro style app that we haven't covered could you provide a brief app scenario to help us better understand the ask?

     

    Thanks,

    -David

     

    Friday, October 28, 2011 11:26 PM
    Moderator
  • http://technet.microsoft.com/en-us/magazine/2007.08.cableguy.aspx

    Yes, IPv6 is in the Windows OS. The article makes the distinction between stateless and statefull address autoconfiguration. No one, however, really points out what statefull means: A server somewhere other than your computer holds IP address information about your connection. This is usually an Internet Service Provider (ISP) or a corporation. And, of course, stateless, means you figure out your own IP and port number, and IPv6  checks to see if it is a duplicate or not.

    A Metro style app shouldn't need to concern itself with the lower level IP configuration.

    The suggested MetroUI networking interface, IMO, already is revealing, if not lower level IP configuration details, the fact that it is Dhcp and server dependent. To correct that there should be a set of Slaac--prefixed functions as well. But there is a problem with that.

    There is no longer a single IP address per PC or device. In IPv6 there can be many per device. Each one of these IPv6 addresses may either be statefull (Dhcp) or stateless (Slaac). Their state (type) is M or O and is carried around in the address header data.

    As a result, I believe the MetroUI Networking API should allow you to create either kind or both. Unfortunately, the current MetroUI networking functions imply that all address types are 1) statefull (ie, require contact with a server somewhere) because of their Dhcp prefix, and 2) by calling DhcpCApiInitialize or Dhcpv6CApiInitialize the whole session’s addresses are only of the one type, Dhcp. So even if there were the capability of creating both kinds, the app would still get initialized as Dhcp.

    For there to be both kinds of address creations, at least the Initialize functions would have to lose their Dhcp prefixes and there would need to be an address creation function that could create Slaac addresses plus functions for their notifications.

    If you haven't had a chance to review them yet, there are a couple //build/ presentations on networking and sockets programming in Metro style apps:

    Creating connected apps that work on today's networks

    http://channel9.msdn.com/Events/BUILD/BUILD2011/PLAT-785T

    Building Windows runtime sockets apps (

    http://channel9.msdn.com/Events/BUILD/BUILD2011/PLAT-580T

    Note the HostName class discussed in this sockets talk at ~22min into the video as this may address some of your needs.

    HostName lets you establish a listener on an endpoint, but it doesn’t let you create a unicast IPv6 address. You need the address in some form before you call HostName and there is no convenient function for getting that without involving a server somewhere (ie, Dhcp).

    If there is a scenario you feel should be available for a Metro style app that we haven't covered could you provide a brief app scenario to help us better understand the ask?

    Regarding scenarios that the MetroUI Dhcp calls will not address, these scenarios fall into the category of Computer Supported Cooperative Work. There are two relevant sub-categories: push vs. pull, asynchronous vs. synchronous. Current http technology is asynchronous-pull and is entirely happy with Dhcp statefull addressing because it is client/server. Asynchronous-pull has no problem retrieving an IP from an ISP or corporation somewhere.

    But synchronous-push does have a problem because there is no server. The Peer to Peer scenarios we support are synchronous-push and have no contact with servers anywhere. They require IPv6’s stateless address autoconfiguration. The main characteristic of this kind of app is N authors/devices/etc. contributing input to M observer subscribers where the M observers have read-only privilege over that which was sent. Synchronous-push makes native remote read-only possible and enables the authoring node to retain ownership of transmitted data and actions. If the observers instead had read-write privilege over the pushed content they received, then the app would be loosely coupled and asynchronous and the author would lose ownership of the content, which is the case with today’s http apps. For us to re-imagine the mobile portion of our apps for the MetroUI, we need synchronous-push, preferably at the non-OS level.

    Upon request I can describe several apps, graphical and textual, of this sort in more detail, but this reply is probably long enough.


    RT
    Friday, November 4, 2011 5:26 PM
  • Hi RT,

     

    Would you happen to have a Metro style sample app that demonstrates the failure to communicate as you describe above? Most Metro style apps would not need to make use of the Win32 DHCP Apis' you mention in order to communicate with peers. The reason I ask for a sample is after some discussion with the Networking team we cannot determine why the scenario you are outlining would not work in the Developer Preview release.

     

    Thanks,

    -David

     

    Monday, November 28, 2011 11:33 PM
    Moderator
  • After our own internal discussions we would like to propose a test for the new MetroUI interface:

     

    Simple Telnet between MetroUI app and MFC app (MFCMetroChat):

     

    The purpose of the test would be to illustrate the synchronous push capability needed by our apps if they were to be ported to the MetroUI.

     

    Simple Telnet functionality would be simulated across the MetroUI/MFC boundary. Inter process communication would be comprised of two TCP sockets, one in a MetroUI app and the other in a traditional MFC app. Two IP addresses would simulate IPv6 stateless address configuration (SLAAC) by using fixed IPv4 addresses with fixed port numbers. In other words the mutual end points would be hard-coded and therefore simulate an IPv6 user creating his own IP address without hitting a server or ISP (ie, not DHCP). Each app would maintain an asynchronous listener and be able to connect asynchronously to the other side. Each side would display text payloads terminated by EOLs as long as they were up and running.

     

    The MetroUI app will be written in C++/wrl.

     

    Requisite knowledge for understanding why this test is necessary and how to develop this test:

    1)      C++ native Windows code developer

    2)      IPv6 SLAAC (see IPv6-04 IPv6 Stateless Address Autoconfiguration (SLAAC) at http://www.youtube.com/watch?v=zbkBa8Zl568 )

    3)      MetroUI C++ development( see

    a.       Tools for building Metro style apps  at http://channel9.msdn.com/Events/BUILD/BUILD2011/BPS-1006

    b.      GoingNative 2: C++ at BUILD, Windows Runtime Library(WRL) at Meet Tarek and Sridhar  at http://channel9.msdn.com/Shows/C9-GoingNative/GoingNative-2-C-at-BUILD-Windows-Runtime-LibraryWRL-Meet-Tarek-and-Sridhar

    c.       Windows Runtime internals: understanding "Hello World" at  http://channel9.msdn.com/Events/BUILD/BUILD2011/PLAT-875T

    d.      Using the Windows Runtime from C++ at http://channel9.msdn.com/Events/BUILD/BUILD2011/TOOL-532T

    e.      Under the covers with C++ for Metro style apps at http://channel9.msdn.com/Events/BUILD/BUILD2011/TOOL-690C

    f.        Tips and tricks for developing Metro style apps using C++ at http://channel9.msdn.com/Events/BUILD/BUILD2011/TOOL-845T

    g.       Bringing existing C++ code into Metro style apps at http://channel9.msdn.com/Events/BUILD/BUILD2011/TOOL-789C )

     

     

    If successful, we can submit the code to SDK as a C++/wrl synchronous push IPv4/IPv6 sample app.

     

    Do you agree that this would be an adequate test of the functionality we expect of MetroUI?


    RT
    • Edited by rtischer8277 Monday, December 5, 2011 7:15 PM typo
    Saturday, December 3, 2011 4:40 PM
  • Hi RT,

     

    This sample proposed appears to be a completely reasonable implementation. A C++ socket sample addition would certainly be welcomed by the community. I did have a couple of points I want to clarify. This is really more for the benefit of those that will run across this post later.

    1.      A Metro style app should not be involved with IP configuration. A Desktop app would be used instead if that is an application requirement you were considering in this sample.

    2.      The sample itself would not be a POC for SLAAC support. SLAAC support would be dependent upon the infrastructure, configured independent of the sample Metro style app.

    3.      Interprocess communication must cross OS boundaries when a Metro style app is involved. The MFC client and Metro style app cannot communicate when running on the same system.

    4.      You mention the use of WRL. We have released little documentation for that library to date. At this time I would recommend using the C++/CX extensions.

    You might consider using telnet for your MFC client to save dev time but the client may need to install it depending on the client OS.

    Thanks,

    -David

    Friday, December 9, 2011 6:31 PM
    Moderator