Not sure if this is a good idea but I would like to try it out.
What I have is a smartpointer returned from a connection class and I want to send it as the players ID, it will need to work for 32 and 64 bit systems
Would it be safe to use a unsigned 64 bit int, will it cover the range, the google protocol buffer has a fixed64 bit value can I use that.
I went ahead and set up a test it does work but how valid is it to do something like this
.
class t
{
public:
t(){}
~t(){}
void Print()
{
std::cout << std::endl << "Printed Using the copyed address" << std::endl;
}
};
int main(void)
{
t *newt = new t();
t *temp = NULL;
Tespointer ptrs;//sfixed64 google protocol
//hold the pointer in the 64bit value
ptrs.set_address((::google::protobuf::int64)newt);
std::string serialized;
ptrs.SerializeToString(&serialized);
ptrs.ParseFromString(serialized);
temp = (t*)ptrs.address();
temp->Print();
_getch();
return 0;
}
Nope, terrible idea. The address of a smart pointer will change between builds, and with features like process address randomization, may change between runs.
What about just each run of the program, the ID would be ok, as long as I don't delete the pointer during the app current run.
Was reading this, but ??? I don't want to convert it to a different type just something to hold the value so it will be the same on a 32bit and a 64 bit
If I keep it a int64_t on a 32 bit system and a 64 bit system sends its ID will the 32 bit system display all its values.
Why do you think you need a 64-bit id? Are you planning to have more than 4,294,967,296 players connected at once? (hint: that's well over half the world's population)
no. I was thinking about using it to link a remote object to its host object.
The host creates a object then tells all remote computers to also create a object then the remote object hold this value for sends back to the host object. to link remote object to host object. Crazy maybe.
My 2 cents: this "pointer-ID" could be used for arbitrary code execution over the network, as long as someone knows the memory layout of your object - which isn't hard, considering all C+ objects and most other types of objects keep a pointer to the virtual methods table right at the start of the object. All they would have to do is send you another "pointer-ID" which points to valid memory that has the same layout. At the least they could start sending random IDs and manage to crash your server with an access violation.
A perfectly acceptable alternative is to just shove the pointer into an array. The player ID is the index into this array. If players can join mid-progress with the game, use a free-list of some sort to recycle player IDs when someone quits the game.
Note also that you don't want the player to ever tell the server who he is. You might tell a player that his ID is 2 and then he might send a command SelfDestruct(player=4) and bam, he just killed another player.
Each connection should have an implicit player ID on the server side. When input is received from a connection then the ID that is associated with it is automatically associated with the input. The player ID should only be used by players to identify other players when _requesting_ things over the network from the absolutely-authoritative server. Requests that affect a player himself should rely on that implicit player ID on the server, not sending the ID to the server as part of the request.
Sean Middleditch – Game Systems Engineer – Join my team!
My 2 cents: this "pointer-ID" could be used for arbitrary code execution over the network, as long as someone knows the memory layout of your object - which isn't hard, considering all C+ objects and most other types of objects keep a pointer to the virtual methods table right at the start of the object. All they would have to do is send you another "pointer-ID" which points to valid memory that has the same layout. At the least they could start sending random IDs and manage to crash your server with an access violation.
Oh the nasty barstards(kill the hackers). Man that sux, That 2 cent just busted the piggy bank. mmmm New plan..
Coordinated unique IDs work well. Start with a block and have the machine maintain a set of numbers.
If you need different machines to generate their own then as part as client negotiation include banks of numbers. Perhaps a block of a million for local objects that never get shared (0-999,999,999) then another bank for shared objects from client 0, (from 1,000,000 to 1,999,999), a bank of a million for client 1 (from 2,000,000 to 2,999,999), and so on.
And that's it. Each client in the mesh (up to about four thousand of them) can generate whatever they want, whenever they want, and share with the mesh. Everybody can generate more shared unique IDs than you need for networked game objects.
That's overkill really, since if your networked simulation is trying to communicate more than a few hundred shared items at once you are likely outside the scope of a realtime game and more in the scope of some type of scientific processing like weather simulation.
Why do you think you need a 64-bit id? Are you planning to have more than 4,294,967,296 players connected at once? (hint: that's well over half the world's population)
That is the range of 32-bit. I think you meant 2^64 = 1,844674407371e+19 or the galaxy's stars several times over
