Jump to content
  • Advertisement
Sign in to follow this  
ankhd

I would like to use a smartpointer's address as a ID value

This topic is 1333 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi all.

 

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;
 }
Edited by ankhd

Share this post


Link to post
Share on other sites
Advertisement

Hi.

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.

Share this post


Link to post
Share on other sites

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)

Share this post


Link to post
Share on other sites

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.blink.png

Share this post


Link to post
Share on other sites
What tonemgub said. This is a bad, bad idea.

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.

Share this post


Link to post
Share on other sites

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..

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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 tongue.png Edited by swiftcoder

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!