C Socket programming question

[Justin Robbs]

I am trying to write the communcations part of a Point of Sale program for
the Convenience Store industry. The setup in each store will have varying
numbers of registers. There could be as few as 2 or as many as 12. The
program I am working on runs on a computer which communicates to our gas
pumps and sends status changes to all registers. It also handles a certain
amount of individual communications to a specific register. Anyway, I am
trying to write a function to run at the beginning of the program to
identify all registers and load their host information into an array up to
MAXREGISTERS in length that way I could have the information available to me
whenever I need to send them information.

I have written a function that looks like this:

void
Find_Hosts()
{
int i;
char myname[MAXNAME+1], gasname[MAXNAME+1], store[5], temp[80],
Remote_Reg[8];
FILE *temp_io_stream;

gethostname( myname, MAXNAME );
sprintf( Local_Gas, myname );

store[0] = myname[2];
store[1] = myname[3];
store[2] = myname[4];
store[3] = myname[5];
store[4] = '\0';

for( i=0; i<MAXREGISTERS; i++ )
{
sprintf( Remote_Reg, "r%ds%s", i+1, store );

/****** DEBUG CODE ******/
if( ( temp_io_stream = fopen( "REG.FIL","a" ) ) == NULL )
{
if( ( temp_io_stream = fopen( "REG.FIL","w" ) ) != NULL )
{
fprintf( temp_io_stream, "%s\n", Remote_Reg );
fclose( temp_io_stream );
}
}
else
{
fprintf( temp_io_stream, "%s\n", Remote_Reg );
fclose( temp_io_stream );
}
/****** DEBUG CODE ******/

if( ( remote_reg = gethostbyname( Remote_Reg ) ) == NULL )
{
sprintf(error_msg_1,"Error Sending Socket: ");
sprintf(error_msg_2,"Unable to get remote register");
error_codes(694);
}
}

if( ( temp_io_stream = fopen( "STORE.FIL","w" ) ) != NULL )
{
fwrite( store, sizeof (char), (size_t) 5, temp_io_stream );
fclose( temp_io_stream );
}
return;
} /* End Find_Hosts */

remote_reg is defined like this:

struct hostent *remote_reg [MAXREGISTERS];

The problem is the value of remote_reg [0] == remote_reg [1]. In the test
scenario MAXREGISTERS == 2.

What am I doing wrong here?

Is this approach not going to work?

How else might I approach this?

The original implementation of this went on the assumption of always having
2 registers, so I simply defined
struct hostent *remote_reg1;
struct hostent *remote_reg2;
I really don't want to have a separate program for each different store
based on the number of registers. I would like to be able to read
MAXREGISTERS from a file and the program run as needed.

Thanks in advance,
justin

 

[Dave Vandervies]

I am trying to write the communcations part of a Point of Sale program for
the Convenience Store industry. The setup in each store will have varying
numbers of registers.

Your problem looks (to me, at least) like it involves what gethostbyname
is doing, which puts it beyond the scope of comp.lang.c. Since this
looks vaguely unixish, comp.unix.programmer would be my first guess at
a better place to ask.

ObC: Is it possible that gethostbyname returns a pointer to a static
buffer? If that is the case, then it will return the same pointer every
time and when you follow the pointer you'll get whatever it stuffed into
that buffer most recently.


dave

 

[Justin Robbs]

Your problem looks (to me, at least) like it involves what gethostbyname
is doing, which puts it beyond the scope of comp.lang.c. Since this
looks vaguely unixish, comp.unix.programmer would be my first guess at
a better place to ask.

ObC: Is it possible that gethostbyname returns a pointer to a static
buffer? If that is the case, then it will return the same pointer every
time and when you follow the pointer you'll get whatever it stuffed into
that buffer most recently.

I am pretty sure that this is what is happening as the value I get is the
value of the last system that was looked up. I thought about posting to
comp.unix.programmer, because it was relating to sockets. I just thought
that since it was more an issure of dealing with a static buffer than
specifically dealing with sockets, this would be an appropriate venue. I
will post the question to C.U.P, but in the meantime could anyone suggest a
way to get around this problem?

Thanks,
Justin

 

[Alan Balmer]

I am pretty sure that this is what is happening as the value I get is the
value of the last system that was looked up. I thought about posting to
comp.unix.programmer, because it was relating to sockets. I just thought
that since it was more an issure of dealing with a static buffer than
specifically dealing with sockets, this would be an appropriate venue. I

If you actually thought that, putting the question in those terms
would have made it clearly on-topic. Why not just copy the results you
want to save before calling the function again?

 

[Justin Robbs]

If you actually thought that, putting the question in those terms
would have made it clearly on-topic. Why not just copy the results you
want to save before calling the function again?

I couldn't think of the terminology to describe it until it was he put it in
those terms. As far as copying the results, I don't know why I didn't think
of that. I guess I was just making it to complicated in my head.

Thanks,
Justin

 

[Alan Balmer]

I couldn't think of the terminology to describe it until it was he put it in
those terms. As far as copying the results, I don't know why I didn't think
of that. I guess I was just making it to complicated in my head.

Yep, in a complex program, it's easy to get bogged down in the
details. For me, network programming is particularly conducive to
confusion <g>. Dave zeroed in on the trouble spot nicely, though. I
expect that c.u.p would have spotted it quickly, too, though they
might have got distracted by other aspects of the code ;-)

 

[Justin Robbs]

Yep, in a complex program, it's easy to get bogged down in the
details. For me, network programming is particularly conducive to
confusion <g>. Dave zeroed in on the trouble spot nicely, though. I
expect that c.u.p would have spotted it quickly, too, though they
might have got distracted by other aspects of the code ;-)

I will probably regret asking this, but what other aspects are there with
the code. I am still somewhat of a newbie. I have learned C mostly from
looking at this program in addition to a couple of books, so I am probably
missing some information. I will take advantage of any opportunity to learn
that I can.

I did post to c.u.p and they came up with the same solution although someone
mentioned gethostbyname_r () which is a reentrant version of gethostbyname.
Unfortunately, I don't have that on my system.

Thanks,
Justin

 

[Dave Vandervies]

Dave zeroed in on the trouble spot nicely, though.

That's what happens when you put a problem in front of a fresh set
of eyes.
My intuition was screaming that there was a C problem hidden behind
all the socket stuff, and seeing the return value from gethostbyname
stuffed into an array of pointers led to what appears to have been an
accurate guess.

I wonder if this means that I've been writing computer programs for
too long. (Not that I'd know what to do instead if it is time for a
career change...)


dave

 

[Alan Balmer]

I will probably regret asking this, but what other aspects are there with
the code. I am still somewhat of a newbie. I have learned C mostly from
looking at this program in addition to a couple of books, so I am probably
missing some information. I will take advantage of any opportunity to learn
that I can.

I didn't see anything particularly obnoxious in your C code, and if
Barry Margolin didn't spot any Unix aspects, that's probably pretty
good, too

I did post to c.u.p and they came up with the same solution although someone
mentioned gethostbyname_r () which is a reentrant version of gethostbyname.
Unfortunately, I don't have that on my system.

The reentrant version is less portable, but some implementations (such
as HP-UX) are at least thread-safe, but that's off-topic here.

However, deep copies were mentioned, and I think that's topical here,
although there's no general solution. What that means is that for
structures which contain pointers, copying the structure may not be
enough,. You may also need to copy the entities the pointers are
pointing to. That's the case here. The hostent structure is:

struct hostent {
char *h_name;
char **h_aliases;
int h_addrtype;
int h_length;
char **h_addr_list;
};

The gthostbyname function returns a pointer to a static instance of
this structure, which will be overwritten on the next call. What may
not be so obvious is that h_name, h_aliases[], and h_addr_list[] may
also be static objects which will be overwritten on the next call, so
you have to copy them as well, else the pointers in your hostent
structure copy will be worthless. What's more, the two arrays are
variable length and null terminated. Getting all this data and
adjusting the pointers to refer to your local copies is called a "deep
copy." It's non-trivial, as you can see.

In real life, you often don't really need all the data (maybe you just
want the host name, for example.) In that case, it may be easier to
make local copies of only the data you need (build an array of
pointers to host name strings, for example.)

 

[Alan Balmer]

I will probably regret asking this, but what other aspects are there with
the code. I am still somewhat of a newbie. I have learned C mostly from
looking at this program in addition to a couple of books, so I am probably
missing some information. I will take advantage of any opportunity to learn
that I can.

I did post to c.u.p and they came up with the same solution although someone
mentioned gethostbyname_r () which is a reentrant version of gethostbyname.
Unfortunately, I don't have that on my system.

See new subject header "Re: Deep copies - was C Socket programming
question".

 

[Justin Robbs]

I didn't see anything particularly obnoxious in your C code, and if
Barry Margolin didn't spot any Unix aspects, that's probably pretty
good, too

That's good to know. I want to write quality code, but when you are
teaching yourself and you don't have anyone to bounce things off of, such as
is this the best way to accomplish x, it makes it difficult.

The reentrant version is less portable, but some implementations (such
as HP-UX) are at least thread-safe, but that's off-topic here.

However, deep copies were mentioned, and I think that's topical here,
although there's no general solution. What that means is that for
structures which contain pointers, copying the structure may not be
enough,. You may also need to copy the entities the pointers are
pointing to. That's the case here. The hostent structure is:

struct hostent {
char *h_name;
char **h_aliases;
int h_addrtype;
int h_length;
char **h_addr_list;
};

Wow, thanks for taking the time to look at the thread over there. Most
people wouldn't go out of their way like that. I appreciate that.

The gthostbyname function returns a pointer to a static instance of
this structure, which will be overwritten on the next call. What may
not be so obvious is that h_name, h_aliases[], and h_addr_list[] may
also be static objects which will be overwritten on the next call, so
you have to copy them as well, else the pointers in your hostent
structure copy will be worthless. What's more, the two arrays are
variable length and null terminated. Getting all this data and
adjusting the pointers to refer to your local copies is called a "deep
copy." It's non-trivial, as you can see.

In looking at the hostent struct more closely and looking at what I was
trying to do, this explanation makes it obvious why it won't work. This has
been a great learning experience.

In real life, you often don't really need all the data (maybe you just
want the host name, for example.) In that case, it may be easier to
make local copies of only the data you need (build an array of
pointers to host name strings, for example.)

Great idea, I only need the host address to pass to my sockaddr_in structure
to make the connection. That will save me a lot of unnecessary code and
keep me from wasting memory loading up the whole hostent structure
MAXREGISTERS number of times.

Thanks for your help.

Justin

 

[CBFalconer]

.... snip ...

I have written a function that looks like this:

void
Find_Hosts()
{

.... snip ...

which neither returns any value, nor receives a pointer to any
object to fill with data, and thus is totally useless. In
addition it can be noted that no "global" variables have been
declared, thus absolutely ensuring that uselessness.

As far as the subject line is concerned, C knows nothing about
sockets.

I suspect A) failure to read the faq. B) failure to lurk and
understand the purpose of c.l.c.

You need to cut your problem down to a complete, compilable
program of about 100 lines or less, which does not use
non-standard constructs or functions (see the C standard), and
post that when asking for help. Do not use // comments (in the
newsgroup) nor exceed about 65 char. lines. Use spaces, not tabs,
for indentation.

 

[Chris Torek]

However, deep copies were mentioned, and I think that's topical here,
although there's no general solution. What that means is that for
structures which contain pointers, copying the structure may not be
enough. You may also need to copy the entities the pointers are
pointing to. That's the case here.

All of this is true. The most important is perhaps that "no general
solution" part, though , because:

The hostent structure is:

struct hostent {
char *h_name;
char **h_aliases;
int h_addrtype;
int h_length;
char **h_addr_list;
};

The gethostbyname function returns a pointer to a static instance of
this structure ...

.... I do not think it is all that wise to "know" this much about the
data structures (even if it is documented). In particular, the
h_addr_list member was once an h_addr member, and in any case the
whole thing is horribly klunky and on sensible systems the entire
routine is replaced by the new getaddrinfo() interface. In other
words, the "unwiseness" aspect is that there is a newer, better
way to handle the situation. (Of course it may not be implemented
on older systems!)

The other C-related lesson that can be drawn here is that it pays
to define good interfaces. In particular, getaddrinfo() is naturally
re-entrant, avoiding the whole "static instance" issue. It has a
corresponding function, freeaddrinfo(), to release any space
malloc()ed inside an earlier getaddrinfo(). (The other thing
getaddrinfo() provides -- probably the real reason the better
interface is finally displacing the old ugly one -- is a sensible
way to handle both IPv4 and IPv6.)

Note that here, the programmer who benefits from the "good" interface,
or "pays for" the bad one, is *not* the programmer who defined it.
This, too, is typical (and not just in C).

 

[Justin Robbs]

All of this is true. The most important is perhaps that "no general
solution" part, though , because:

I've always felt that for the most part "general solutions" to any problem
are overly complex and in the long run prove to be horribly inadequate.

... I do not think it is all that wise to "know" this much about the
data structures (even if it is documented). In particular, the
h_addr_list member was once an h_addr member, and in any case the
whole thing is horribly klunky and on sensible systems the entire
routine is replaced by the new getaddrinfo() interface. In other
words, the "unwiseness" aspect is that there is a newer, better
way to handle the situation. (Of course it may not be implemented
on older systems!)

My system would be one of those systems that doesn't have getaddrinfo(). I
am developing on SCO OpenServer 5.0.5.

 

[Justin Robbs]

... snip ...

which neither returns any value, nor receives a pointer to any
object to fill with data, and thus is totally useless. In
addition it can be noted that no "global" variables have been
declared, thus absolutely ensuring that uselessness.

As far as the subject line is concerned, C knows nothing about
sockets.

I suspect A) failure to read the faq. B) failure to lurk and
understand the purpose of c.l.c.

You need to cut your problem down to a complete, compilable
program of about 100 lines or less, which does not use
non-standard constructs or functions (see the C standard), and
post that when asking for help. Do not use // comments (in the
newsgroup) nor exceed about 65 char. lines. Use spaces, not tabs,
for indentation.

Sorry to all who were offended. I thought that I provided enough
information to get my question answered. I didn't realize that I had to
provide a small compilable program to get help. I will read the faq before
I post another problem.

Thanks to all who helped me inspite of my poor netiquette.

Thanks,
Justin

 

[Christopher Benson-Manica]

post that when asking for help. Do not use // comments (in the
newsgroup) nor exceed about 65 char. lines. Use spaces, not tabs,

65? Does anyone read newsgroups on a <80 column terminal anymore?

 

[Alex]

CBFalconer <[email protected]> spoke thus:

65? Does anyone read newsgroups on a <80 column terminal anymore?

Probably not. IIRC the idea behind the 65 characters is to leave
sufficient space for quoting in subsequent replies. That way, the
original text is not likely to exceed the standard 80 columns.

Alex

 

[Ben Pfaff]

65? Does anyone read newsgroups on a <80 column terminal anymore?

The purpose of the 65-column rule is to allow quoted lines to fit
within 80 columns.

 

[Joona I Palaste]

The purpose of the 65-column rule is to allow quoted lines to fit
within 80 columns.

And what if a message is quoted more than 15 levels deep? What then?
Hmm? Oh yes, right. Messages shouldn't be quoted that deep, or there's
something severely wrong with you.

--
/-- Joona Palaste ([email protected]) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"The day Microsoft makes something that doesn't suck is probably the day they
start making vacuum cleaners."
- Ernst Jan Plugge

 

[CBFalconer]

65? Does anyone read newsgroups on a <80 column terminal anymore?

You normally set the message composition software to wrap at 65 or
so so that even after a few passes through quoting (added "> > >
") the result remains legible. The editor is not usually capable
of discriminating between source and text.