There are lots of factors to take into account, type of game, speed of connection, number of peers, how much data you want to send, if people have limited bandwidth allowances you don't want to over use, is this over a LAN or internet, etc.
Lets say for example, you have a 64kbs (64 kilobits per second or 8 kilobytes per second) connection (which is slow by modern standards for average home internet but not necessarily slow for phones), with 8 players and you want to update as often as possible for a real-time game, you'll need to send to 7 people at most 9kbs each (64/7). Assuming your update packet size was 1kb (1024 bits or 128 bytes) for each update, you'd only want to send an update roughly 8 times per second, or put another way for a game running at 60fps, every 7 or so frames.
You'll need to do your own calculations based on what your target bandwidth is, packet size, etc. There's nothing standard that will scale this for you, however it's fairly easy to keep track of when the last update was done and not send another for X frames or X milliseconds, etc. When calculating the size of your packets, you'll also need to take into account packet header sizes which will potentially vary by the platform you use and apply and a specific overhead to sending anything (which for UDP over IPv4 seems to be 20 bytes).
UPDATED due to extra info (and switching TCP reference above for what it should have been, UDP): You'll want to be using UDP instead of TCP as the overall overhead of TCP is more than you want in a real-time game. You don't need/want the guaranteed delivery of packets as it'll require each packet to return a successfully delivered reply (plus by the time it's then re-sent the data is out of date anyway). For the internet you'll need to assume at least a certain level of packet loss and how you cope with this (you can even simulate this in your code by randomly not sending or not sending every Xth packet). You'd also using UDP need to take into account that packets can arrive in a different order to that being sent, so you'd also probably want to send some sort of number (be it time, or some incrementing value) to indicate that if you receive packet 200 first, then that's the current good state and then receiving packet 199 it should be ignored.
You could also potentially do other network optimisations, such as sending a less frequent "big" update (say position, orientation, velocity, etc) with more information, then send more "smaller" partial updates (such as controller input, or delta's). Smaller packets allow more to be sent for the same bandwidth (again you need to take into account packet header overhead, you want to have a good ratio of actual data sent to header size).
This mostly applies to peer-2-peer over the internet. If this is just for a local area network (unclear from the question), then it probably isn't a concern on how often you send the data unless the actual sending or receiving the data is somehow computationally expensive (not usually). You'd most likely want to send it as fast as you can in a LAN environment for responsiveness.