|
Home > Archive > Unix Programming > October 2005 > Server sockets and threads.
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Server sockets and threads.
|
|
| weirdo 2005-10-24, 3:47 pm |
| Hello everyone.
I'm not sure weather my problem is causing due to socket problem, or a
bad class design.
Anyway, I was trying to implement a class which handles BSD sockets and
sockaddr_in structure, using POSIX threads.
The class is designed to implement both server and client programs.
In it's c'tor it gets address and port.
If the Sock::Listen() member function is called, the BSD bind and
listen function are called, and a new thread initiated for accepting
clients. Each of these clients is represented as a Sock class, and it's
pointer is saved in a list of clients. (The list is a member of a
derived class from Sock).
Each of these clients also initiate a thread for reading from the
server.
it's really defficult to supply a sketch of the class map.
it's something like this:
Server -> Client list.
Thread function: Get client and append it to Client list.
Client -> Thread function: a = read (...)
if (a>0) {print} else {ERROR - Bad FD}
what can cause the problem:
"bad file descriptor" on the server side.
For some reson the pipe is breaks after two reads call.
might it be the fact that the m_nSocket (the fd) is a private member??
what could cause that problem??
| |
| David Schwartz 2005-10-24, 3:47 pm |
|
"weirdo" <avikam@gmail.com> wrote in message
news:1129310061.042033.235470@g44g2000cwa.googlegroups.com...
> Client -> Thread function: a = read (...)
> if (a>0) {print} else {ERROR - Bad FD}
> what can cause the problem:
> "bad file descriptor" on the server side.
Your code is doing one of two things wrong, and it's hard to tell which:
1) It's lying and saying it got a "bad file descriptor" error when it
actually got some other error.
2) It's trying to do an operation on a value that's not a valid file
descriptor either because it didn't properly set the value, corrupted the
value, or closed the descriptor while it was still using it.
In either case, it's an application bug. You realize that 'read' can
return '0' and this is *NOT* an error and you should *NOT* check errno.
DS
| |
| weirdo 2005-10-24, 3:47 pm |
| Fotunetlay i'v solved the problem.
The problem was (2) as suggested above - the fd was actually closed.
The source of this problem really was the design of my classes.
One tip to learn from past's mistake:
It is no wise (at least in my opinion) to close a socket within a
destructor function. That is because classes instances which hold such
precious information as the socket descriptor might be closed lots of
time (in hebrew we say: on left and right) and in every function call
or dynamic allocation, those destructed objects corrupt the socket.
Another question: When I closed the connection from oe side, the other
side said something like: "connection reset on the ** side" (this error
message was retrived from strerror function).
But when I accedintly closed the socket (as I described above), the
other side only complained about a broken pipe. It did not say that the
connection was reset on the other side. why??
Defacto, that message could really helping me debug the problem?
Is their some incomplecity in the BSD sockets?
| |
| weirdo 2005-10-24, 3:47 pm |
| Fotunetlay i'v solved the problem.
The problem was (2) as suggested above - the fd was actually closed.
The source of this problem really was the design of my classes.
One tip to learn from past's mistake:
It is no wise (at least in my opinion) to close a socket within a
destructor function. That is because classes instances which hold such
precious information as the socket descriptor might be closed lots of
time (in hebrew we say: on left and right) and in every function call
or dynamic allocation, those destructed objects corrupt the socket.
Another question: When I closed the connection from oe side, the other
side said something like: "connection reset on the ** side" (this error
message was retrived from strerror function).
But when I accedintly closed the socket (as I described above), the
other side only complained about a broken pipe. It did not say that the
connection was reset on the other side. why??
Defacto, that message could really helping me debug the problem?
Is their some incomplecity in the BSD sockets?
| |
| Maxim Yegorushkin 2005-10-24, 3:47 pm |
|
weirdo wrote:
> The source of this problem really was the design of my classes.
> One tip to learn from past's mistake:
> It is no wise (at least in my opinion) to close a socket within a
> destructor function. That is because classes instances which hold such
> precious information as the socket descriptor might be closed lots of
> time (in hebrew we say: on left and right) and in every function call
> or dynamic allocation, those destructed objects corrupt the socket.
You hit the ownership problem. It's solved usally by making the class
holding resources noncopyable, or making resources reference-counted so
that the last resource user releases a resource.
> Another question: When I closed the connection from oe side, the other
> side said something like: "connection reset on the ** side" (this error
> message was retrived from strerror function).
> But when I accedintly closed the socket (as I described above), the
> other side only complained about a broken pipe. It did not say that the
> connection was reset on the other side. why??
Probably because you started writing without reading the socket first
or getting its error state (getsockopt(..., SO_ERROR, ...)).
|
|
|
|
|