p********p
发帖数: 5 | 1 My program (running on Solaris) will run into the poblems during the
high traffic time period. The piece of code looks like :
listen(socketdescriptor, 800);
for (;;) {
int socketno;
struct sockaddr_in clientaddress;
int addresssize= sizeof(clientaddress);
if ((socketno=accept(socketdescriptor, (struct sockaddr *)
&clientaddress,
&addresssize))<0) {printout error mesage;}
else {
put the "socketno" into a request queue, and other seperate
processing threads will | p******f
发帖数: 162 | 2
when you said communication error, did you mean connect(2) returned
-1, or it came from read(2) or write(2)? it is strange that these
function can return ENOENT, which is not documented on my system (linux).
800 should be big enough. if the connection pending queue is full,
the SYN from client will be silently dropped, and the client will
resend it again, until some timeout value, and then connect(2) will
return ETIMEOUT.
【在 p********p 的大作中提到】
: My program (running on Solaris) will run into the poblems during the
: high traffic time period. The piece of code looks like :
: listen(socketdescriptor, 800);
: for (;;) {
: int socketno;
: struct sockaddr_in clientaddress;
: int addresssize= sizeof(clientaddress);
: if ((socketno=accept(socketdescriptor, (struct sockaddr *)
: &clientaddress,
: &addresssize))<0) {printout error mesage;}
| p********p
发帖数: 5 | 3
Thanks, Clients first get read() error and the errors I often saw are "ENOENT"
and "ERROR 0". then the clients try to reestablish the connection by calling
function connect(), and connect() subsequently return "connection refused"
error. The weird thing is clients ran into the same problem. I have been
struggled with this problem for quite a while, but I was unable to figure it
out. Thanks for your help.
【在 p******f 的大作中提到】
:
: when you said communication error, did you mean connect(2) returned
: -1, or it came from read(2) or write(2)? it is strange that these
: function can return ENOENT, which is not documented on my system (linux).
: 800 should be big enough. if the connection pending queue is full,
: the SYN from client will be silently dropped, and the client will
: resend it again, until some timeout value, and then connect(2) will
: return ETIMEOUT.
| m*****e
发帖数: 4193 | 4
Read never returns ENOENT, at least no POSIX systems. So something very wrong
is there.
【在 p********p 的大作中提到】
:
: Thanks, Clients first get read() error and the errors I often saw are "ENOENT"
: and "ERROR 0". then the clients try to reestablish the connection by calling
: function connect(), and connect() subsequently return "connection refused"
: error. The weird thing is clients ran into the same problem. I have been
: struggled with this problem for quite a while, but I was unable to figure it
: out. Thanks for your help.
| p********p
发帖数: 5 | 5
(linux).
"ENOENT"
calling
wrong
it
Here is my client code. The client tries to read a certain bytes from socket
using "mysocketread" function, this function won't return until it gets all
the data it requires, or something gets wrong during the read(). upon the
return, if the client finds the returned bytes and required bytes are
different, it will print out a strerr(errno) which sometime is "No Such file
or directory".
main {
....
FD_ZERO (&desc);
FD_SET (sockdesc, &desc);
struct socketheader
【在 m*****e 的大作中提到】
:
: Read never returns ENOENT, at least no POSIX systems. So something very wrong
: is there.
| p******f
发帖数: 162 | 6
return value of mysocketread less than bytes is caused by unexpected
EOF on socket, which is not an error with regard to read(2), so errno
is not set in this case. you should only check errno when any syscall
returns error (normally -1).
【在 p********p 的大作中提到】
:
: (linux).
: "ENOENT"
: calling
: wrong
: it
: Here is my client code. The client tries to read a certain bytes from socket
: using "mysocketread" function, this function won't return until it gets all
: the data it requires, or something gets wrong during the read(). upon the
: return, if the client finds the returned bytes and required bytes are
| p********p
发帖数: 5 | 7
Thanks very much. So the question is what are the most likely reasons that
mysocketread run into unexpected EOF? Since all the packages the server send
out always contain a header (this header indicated the length of real data),
how can it become EOF? Another question: why after this, the client will get a
"connection refused" error while trying to reconnect? Thanks again
【在 p******f 的大作中提到】
:
: return value of mysocketread less than bytes is caused by unexpected
: EOF on socket, which is not an error with regard to read(2), so errno
: is not set in this case. you should only check errno when any syscall
: returns error (normally -1).
| p******f
发帖数: 162 | 8
run tcpdump or ngrep to look at the packets sent and recieved, this might
solve both question.
【在 p********p 的大作中提到】
:
: Thanks very much. So the question is what are the most likely reasons that
: mysocketread run into unexpected EOF? Since all the packages the server send
: out always contain a header (this header indicated the length of real data),
: how can it become EOF? Another question: why after this, the client will get a
: "connection refused" error while trying to reconnect? Thanks again
| p********p
发帖数: 5 | 9 Thanks very much. I believe I am getting closer to inentify the
problem. There are some problems with my server code.
actually the server process is terminated by some reasons. But I don't
know what causes this. I guess, 1) might because the server calls
assert() to abort the process. If this is the case, there should be
coredump generated, but I could not find core files. 2) might be
caused by system signal, most likely SIGPIPE. However, as far as I
understand, my server code sets the signal h |
|
