If I have cars on the server, or player controlled cars, what would be the best method detect collisions with them in Unity? The cars are updated with with one packet per second, each packet containing state messages of 30 physics ticks. The best thing I came up with is to have the cars with rigidbodies, and have a trigger collider that is at the players position ~1+latency seconds in the past, check for collision with an OnTriggerEnter function.

I forgot to mention that the players are also updated at 1 second intervals with 30 state ticks. The physics are processed 30 times a second.

For a direct answer, a bounding box or two around the vehicle then either OnTriggerEnter or OnCollisionEnter depending on how your objects are configured for collision.

Probably a much bigger concern: Why are you mixing Unity physics with networked multiplayer code?

Unity physics will be inconsistent between machines. Some options are to have your server run all the physics code and transmit the authoritative positions to the clients, or you need to have one machine run the Unity physics for the key objects and everyone else run with physics disabled relying on the server's location, or perhaps have everybody use their own physics and you do your best to push the objects back toward a main state while knowing each player's simulation will be visibly quite different.

Also, sending a packet only every second is likely not often enough for a game that's intended to be highly physics interactive (such as almost all car-based games.)

After that, you really need to define how much latency is OK for you, and how your game design wants to deal with it. For example, it will VERY LIKELY be the case that, on machine A, player A will think that thon is front/left of player B. Meanwhile, on machine B, player B will think that player A is behind/left. If player A now does a lane shift to the right, will the outcome be:
1. Player A is ahead of B in the same lane (looks correct for A)
2. Player A is behind of B in the same lane (looks correct for B)
3. Player A actually sideswipes player B (what likely happens on the server.)

You have to figure out how your physics and networking interact in this case, and then design your game to make sense in this situation. Then you have to code that up -- and exactly what that looks like, depends on your game design.

I was planning on using the rigidbody on the car since I want them to behave like cars, and it's much more simple and productive to use the built in physics than to make my own.

From the tests I ran with Unity physics with rigidbodies, the outcome looks to be deterministic as long as all code pertaining to them is kept in FixedUpdate, that includes instantiating.

Although I don't know if precision errors will make it different on different machines.

If using rigibodies is too problematic, I was thinking about overiding the affected object's states from a collision on client machines with states on the server until the objects settle, instead of handling the interactions with OnCollision functions on the client.

I think I can update the cars from the server to client at maybe 5 updates per second with 6 ticks in each if I need to.

From the tests I ran with Unity physics with rigidbodies, the outcome looks to be deterministic

It may look that way, but it is not.

The Unity physics system is not deterministic. Even if you give it exactly the same starting conditions and it happens to look the same to you, it still is not deterministic.

The Unity physics system was not designed for physics-based networked play, and is a very bad fit if you attempt it. You can have networked games in Unity, you just cannot rely on Unity's physics in the way you want to use it for a racing game.

For some styles of games the networking and physics systems can work well together. You can have a bunch of players standing next to each other in an RPG-style game, each owning their own network-shared collision object. This works just fine because if someone gets too close and clips there are no catastrohpic failures. It may look terrible as they are overlapping, nudged, and corrected but eventually the collision will be resolved by pushing each other away slightly since each one owns their own physics object and each treats their own as authoritative. All physics is doing in that case is nudging other players out of their personal space bubble with no other effects, and if they happen to overlap for a time there is no serious consequence. You can have an army of people who are all standing on the same spot, eventually they'll push each other out of the way but nothing serious will happen.

In a racing game the very same collision is unacceptable, the players will crash or collide and various race-related crashing things will happen.

It's not necessarily a racing game, but I wanted to have cars in it, although they're not essential. I could have hover boards or something else that doesn't really need physics between two dynamic objects.

I think if I can't use the built in physics it will be too much of a hassle to implement my own deterministic physics.

Actually, I wonder if it would be feasable to simulate on the clients and server and send occasional absolute positions and correct the cars over time.

I found this which seems like it will work for me:

http://stackoverflow.com/questions/8324283/how-to-sync-physics-in-a-multiplayer-game

I wonder if it would be feasable to simulate on the clients and server and send occasional absolute positions and correct the cars over time.

Yes, this can work. If the cars are "scenery" and seldom actually collide, and/or don't matter much for the gameplay, then users might not care about the occasional inconsistencies. If the cars are an essential part of gameplay, users may feel that it's "too glitchy," though.