I’d consider bullet trajectory cosmetic – it doesn’t matter how client shows it; impact of this bullet would be handled by the server, and server will multicast whatever happens to impacted surface/actor.
If bullet starts travelling based on starting parameters, these parameters will be determined by the server. Bullet that executes on the server could then interact with impacted actor. This actor will then replicate what happens next.
In this approach, only initial ‘shoot’ packet needs to be multicast, and later ‘impact’, without having to replicate, on each frame, movements of all those 100 or so bullets that Lyan said he’d have…