I have been trying to wrap my mind around incorporating a fixed time step (dewitters game loop) into my game for almost three months now, but I just can't seem to conceptualize it in my mind for my game. I've read posts upon posts, articles upon articles, but still have a lot of questions.
So in short most of the articles say (and my understanding is), you separate the "updates" from the "render" and then use the difference in time and pass to the render to interpolate.
Others have mentioned it and I'm sure you've read it already, but this article is what helped me to fully understand this concept: http://gafferongames.com/game-physics/fix-your-timestep/.
To quote from the article, this sentence specifically describes conceptually what needs to happen:
"The renderer produces time and the simulation consumes it in discrete dt sized chunks."
What does this mean? It means that in your game loop, the first thing you do is check the time (t0), render a frame, and check the time again (t1). Assume for example that time elapsed between t0 and t1 (t1 - t0) is 34 milliseconds. Assume also that your "fixed timestep" for your physics/updates is 10 milliseconds (dt). The "render" stage produces 34ms, and the the "update" stage consumes the time in "discrete dt sized chunks"--that is, 10 ms chunks. That means that for this frame, you will run your update procedure 3 times, stepping forward by 10ms each time. Then you're going to have some time leftover: 4 ms. It is with this remaining value that you interpolate on your next render call.
When they say render are they speaking the actual process of drawing on the screen or the setting of values in the render (sprite x/y)?
Yes. When drawing, you interpolate position based on how far you are "between frames". In this case, you're about halfway between. I imagine this would not only to sprite position, but also to animation states, assuming those movements are also time-based.
To summarize, you basically end up with an update system which lags 1 frame behind the rendering. This may seem "wrong" somehow, but it works.
I can't help much with the networking portion of things (I've never programmed networked games), but I think using a queue somehow is the right approach.
If it helps, here's a real working example of such a loop that I wrote in Java: https://github.com/larsbutler/gamedemo/blob/master/src/com/larsbutler/gamedemo/core/Kernel.java#L68-L104
It's been a few years since I wrote that and some of the code is there is pretty odd, but that particular game loop is pretty solid, IMO.
Hope that helps.