I have been working with an engineer for weeks trying to figure out why we were not able to push to multiple publishing points on the same server using the Windows Media Format SDK. I know that there was a bug in the Format SDK that prevented multiple push sinks from working. That bug was fixed a couple of years back (943335) and is included in the latest version of the Format Runtime.
If you enabled the registry setting described in (943335), you could push to two publishing points at the same time. If you added a third push sink, the Format SDK application appeared to hang. One of the three publishing points started but then they never received data from the application. The server was just sitting there waiting for data, and the client was completely hung up.
During debugging into the windows sources I could confirm that the fix was working as expected. The fix basically allowed WinInet sessions to be spawned as needed for additional push sinks giving each session a unique ID via a HTTP cookie. Typically you would expect one session per push sink. The Format SDK doesn’t spawn a new WinInet session for each sink right away. Complex logic is used to determine when to create a new WinInet session. The code was modified so that each push sink session got its own cookie to identify the push sink within the newly spawned session. Again I could confirm that this code functioning correctly.
Additional debugging showed that the Format SDK code was doing the right thing. However, it was just sitting there waiting for WinInet to confirm a “write” operation. This confirmation was never received. Since this section of the Format SDK code was a single threaded state machine, confirmation from WinInet that the data was written was required before additional data could be sent.
Because of this we were able to narrow the problem down to WinInet, not playing well with others. But why, would this component allow a third session to be created but not allow data to be written to this session? After talking to some of the resident WinInet experts, WinInet has a fundamental limitation of two simultaneous sessions. At this point the light went on. We knew that IE had a limitation of two download sessions but had no idea that this echoed into the world of WinInet.
We found that WinInet has a registry key that can be set to the maximum number of per process sessions (KB 282402). After modifying this registry key to equal the number of push sinks configured in our application, lo-and-behold everything started working as expected. No more hang and all publishing points started getting the data.
The question that I asked was why the original KB 943335 describing the multiple push sink fix did not include the information about the WinInet limitation. The answer that I got was, “please update the KB”. So I’m going to go ahead and put in a request for the change. It probably won’t get updated right away so I thought that I needed to get a blog out about this issue while we wait for the update.
To allow more than 2 push sinks to be enabled within a single process you need to set the following registry keys:
HKCU\Software\Microsoft\Windows Media\WMSDK\General\MultiplePushToSameServer (DWORD)
Set this value to “1”.
HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\MaxConnectionsPerServer (DWORD)
Set this value to the maximum number of publishing points that you will be pushing to, for example “7”.
FIX: Encoder objects try to create multiple push publishing points on a Windows Media server from a single process
How do I configure Internet Explorer to download more than two files at one time?