It depends on your game.
Usually, by 'turn-based', people mean a game with discrete player positions. For example, in Chess, a piece can only be in one of 64 different places. So there's no need to send updates during movement, because movement can be represented instantly (eg. Bishop from B1-E4). The receiving side can decide to animate that if it wants - but that's a presentation decision, not something intrinsic to the rules of the game, and there's not usually a reason why the sender would need to explicitly show the game object moving through those intermediate positions. So typically there would be one message sent, describing the change in terms of the game rules. You wouldn't send hardware-specific input (eg. button presses), nor would you need to send start/stop actions, because you can usually describe it adequately in one message.
Even if you do have a continuous game world (as opposed to a discrete one), there's still no need to be sending updates in real-time. It's a turn-based game and all that matters is that the other player gets to see what happened during the turn and gets an accurate representation of the game state at the start of their next turn. So when you send the updates is up to you, as long as the recipient gets all the information they need to recreate the events of the past turn, and the game state at the start of this turn.
Most games are essentially real-time, which has different requirements. You need regular updates of the other player positions in order for them to be valid at all times. In this case, the simplest situation is just to broadcast the player's current state, all of the time, so that the other computers can just update their local values based on the new information. It also helps to broadcast start and stop messages so that any guesses about what a player are doing (eg. extrapolation based on past velocity) can be corrected if necessary.