avatar
Socket programming help# Unix - 噫吁兮,危乎高哉
p*p
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
avatar
p*f
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;}

avatar
p*p
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.

avatar
m*e
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.

avatar
p*p
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.

avatar
p*f
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

avatar
p*p
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).

avatar
p*f
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

avatar
p*p
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
相关阅读
logo
联系我们隐私协议©2024 redian.news
Redian新闻
Redian.news刊载任何文章,不代表同意其说法或描述,仅为提供更多信息,也不构成任何建议。文章信息的合法性及真实性由其作者负责,与Redian.news及其运营公司无关。欢迎投稿,如发现稿件侵权,或作者不愿在本网发表文章,请版权拥有者通知本网处理。