You are not logged in.
Pages: 1
How can we send data when its pointer.
i have
struct client_hello_info
{
char *username;
char macid[MAC_LENGTH];
int osid;
}my_client;
struct data_packet {
int command_id;
char * data;
int msg_length;
}my_data;
username=malloc(7);
strcpy(username, "santosh")
strcpy(macid, "11:..90");
copied myclient structure into my_data.client
my_data.client=malloc(len)
memcpy(my_data.client, myclient, len);I have to send data_packet from client to server!
but thinking how to send data bec pointers become invalid in diff machines!
copying in big buffer and sending! tats doing twice here ! any better ways?
Offline
struct some_struct {
char name[FIXED_LEN];
int len;
char *somevalue;
};
...
void send_my_struct(int sd, struct some_struct *s) {
send(sd, s->name, FIXED_LEN, 0);
send(sd, s->len, sizeof(int), 0);
send(sd, s->somevalue, len, 0);
}Offline
Offline
Offline
struct client_hello_info
{
char *username;
char macid[MAC_LENGTH];
int osid;
}my_client;
struct data_packet {
int command_id;
char * data;
int msg_length;
}my_data;
username=malloc(7);
strcpy(username, "santosh")
strcpy(macid, "11:..90");
copied myclient structure into my_data.client
my_data.client=malloc(len)
memcpy(my_data.client, myclient, len);Offline
Very valid point... However, your null-termination code is a bit overly paranoid and
not entirely necessary... strcpy() by itself will always null-terminate the destination,
so there's no need to manually do so... (And, if it didn't, then your strlen() of the
destination would be a very bad thing to do at that point, anyway, because it requires
null-termination!) Perhaps you were thinking of strncpy(), which may fail to null-terminate?
Of course, the simplest way to do what's wanted in a guaranteed proper manner is:
username = strdup ("santosh");
(And, check for failure (NULL), just as with all *alloc() functions, too...)
Offline
Not to be a contrarian but...
In response to using a memory pointer as a handle - my thought is that you should NEVER use a raw memory pointer is such a way... either a hash against the data or a secure one way hash against the pointer value should be used...
Here is the rationale... consider where you are sending raw pointers AND it turns out your code has a bug e.g. an overflow bug that allows a malicious user to force data in a specific memory location(s) to be sent back...
In such a situation, then by giving them a raw pointer you are giving the attacker the EXACT location in process memory they ( may ) want to access and make the job of compromising that data that much easier... additionally it may then give them the information to iterate through the rest of in memory records e.g. think of a linked list node where the next record pointer is contained in the structure...
On the other hand - hashing it securely first doesn't give away any 'secrets'... and means they will have to coerce your system into dumping EVERYTHING... or best case - dump it incrementally starting at one end of the heap - figure out where the first segment of desired data it... and then move forward... which is a much harder task...
Michael
"The only difference between me and a madman is that I'm not mad."
Salvador Dali (1904-1989)
Offline
You can pass the heap address to another process. In that way you dont need to pass a big buffer. Other process can read the heap of other process , this is done as part of late binding.
Pages: 1