You are mistaking the call of a remote event script signal with the network ingress step. Both the network ingress and egress step fire once per frame (where “frame” is as I defined it in my previous post). During the network ingress step, any remote calls that have been received and can be acted on at that time are dispatched with the OnServerEvent or OnClientEvent script signals. There may be multiple remote calls that meet these criteria on any given frame due to network unreliability/randomness.
But what do I mean by “can be acted on” ? Roblox implements a per-server-client connection reliability and orderedness protocols for remotes. On a conceptual level, this means that any remote calls you make are guaranteed to arrive at their destination (barring any termination of client-server connection due to a player leaving the game or what have you) and to be dispatched at their destination in the exact order in which they were called at their origin. On a more technical level, this requires the following implementations: acknowledgment messages to ensure reliability, headers appended to remote call packets encoding order (as well as the relevant remote instance), and buffering on the receiving end to cache remote calls prior to the ingress step and prior to any remote calls which were sent before them arriving. Hence, by “can be acted on,” I mean that, given server/client A and server/client B and the sequence of calls from A to B denoted by call_AB1, …, call_ABn, then call_ABi can be acted on only if i is 1 or call_AB(i-1) has been dispatched.
Hence, because of the inherent unreliability/randomness of networking, put together with roblox’s remote protocols, you can imagine why you’re getting those receive intervals. The reliability and orderedness protocols create a real issue for developers who need to send network data at 60 Hz or somewhere near that rate. One packet may get lost and hold up those following it for an intolerable amount of time. And devs, depending on their use case, may be better off discarding such packets, especially if they need near 60 Hz state replication.
The Networked Stepped event would only be necessary if outgoing remote event calls were sent a rate below the framerate (where “frame” is as I defined it in my previous post). They are not sent below the framerate, and hence you do not have to worry about sending duplicate data nor sending data at an insufficient rate (60 Hz is solid).
The essential networking feature request is that roblox allows us to opt out of reliability and orderedness. These protocols being forced is the one and only outstanding issue I can think of with respect to roblox networking. Any others (like multiple OnClient/OnServerEvent invokations per frame) ought to be fixed by developer implementations on a per-use case basis.
I hope this is helpful for you and anyone else who comes across it. My only goal in coming back to this thread was to provide info for everyone who, when trying to learn the roblox networking particulars relevant to them, resorts to sifting through the dev forum where just about everybody else is in the dark because the official documentation is awful. That’s why I was so heavy with the details. I’m not trying to win a “who knows more” contest or anything, so please don’t take it that way.