fakessh said:
I'm working on a client server in c
the base c is the source of the deposit github
that here
I did check the sources they seem perfectly consistent with
standard of writing in c
compile on my machine and my server s performs perfectly
well
How do you know? All I would give it in terms of "performing
prefectly well" might be that it doesn't crash immediately,
but that's a pretty low standard for "perfectly well";-)
but yet I can not connect the client to the server
hosted on a remote machine
can you help me solve the problem of connection to the server
from the client
As others have pointed out it not standard C what you're
using - you use lots of POSIX extensions to C (and you need
to since C has no built-in functions for networking). Thus
it would be reasonable to ask in e.g. comp.unix.programmer
instead.
I also took a short look at the code and there are quite a
number of things that don't make to much sense also from a C
point of view. At least defining functions in header files
already has been mentioned as a no-no. But let's look some-
thing from client.c. You have there
char buf[MAXLINE]; ....
printf("\n\n---input message:\n");
memset(buf, 0, sizeof(buf));
This is completely useless.
scanf("%s",buf);
if(sizeof(buf) > MAXLINE) {
This can never be the case. You defined 'buf' to have
'MAXLINE' chars and that's not going to be changed by
anything you do later, thus sizeof(buf) will always
be 'MAXLINE' (as long as you do it in the same function
you defined the 'buf' array in). Did you perhaps confuse
the sizeof operator with the strlen() function?
printf("\n*** message is too large*** \n\n");
Assuming you meant to use strlen() and not the sizeof ope-
rator, it's actually too late. Once you read in more cha-
racters than 'buf' can hold you already have an evil bug.
What you need to do is restrict the number of characters
you read in in order to avoid a buffer overflow.
close(sockfd);
exit(1);
}
if((write(sockfd, buf, sizeof(buf)) ) == -1) {
{ ....
}
Not a C question, but anyway: why write the whole buffer even
if there is perhaps only a single character in it? A more sane
approach would seem to send first the number of bytes you're
going to send and then the string (use strlen() then instead
of sizeof).
The server part doesn't seem to make much sense. It looks
like a lot of misunderstandings about how select() works
(note that this isn't a C function but a POSIX extension)
and all in all much too complicated. What about boiling it
down to something simple that doesn't do anything but lis-
tening and reading on a socket? As far as I can see you
actually don't ever read on the socket when select() tells
you that there's something to read from it. But that's all
pretty off-topic here, comp.unix.programmer would be way
more suitable for discussions about it.
But even if everything would work perfectly well with regard
to the networking stuff already the few lines for reversing
the string the server received from the client (which it then
obviously is meant to send back) are broken:
x = strlen(buf);
memset(buf_client, 0, MAXLINE);
for (j = 0; x>=0; x--, j++)
buf_client[j] = buf[x]
After this the very first character in 'buf_client' is the
'\0' character (but then there's none at the end)! This sug-
gests strongly that something not very well thought through
is done here. Perhaps it would be instructive to write a
simple reverse() function and test it without all the net-
working stuff before going any further?
But the whole code suffers so much from mixing string lengths
with buffer lengths etc. that one at best can roughly guess
at what the intensions might have been. There's not much I can
see that would make too much sense - at least nothing that I
would call to "work perfectly well".
BTW, the code was uploaded nearly 9 months ago. If it's by
you why come here that much later? And if it's not by you
(as I guess and hope) I would recommend strongly to find
something better than this for trying to learn how to do
network programming. There are a number of good books on
this topic or, if you can't get your hands on them, also a
number of useful tutorials on the net.
Regards, Jens
