Scott,
Thank you for your thought provoking post.
I am using SOCKUTIL that I downloaded from
http://www.scottklement.com/rpg/socktut/socktut.savf .
In reality, my program contains SOCUKUTIL simply because my I used one of
your sample server programs (SERVEREX1 from the same savf) - I do not see
where any of the functions from SOCKUTIL are being used. I will remove it
entirely from the my server if it turns out I do not need it!
The server program is really very simple :
- it makes the listener;
- accepts an incoming connection;
- talks to the client;
- closes the connection socket.
In an attempt to better understand what might be happening, I added a
logging file to the server. The one thing that I gained from this log is
that the server appears to do nothing to stop the connection. A review of
the netstat connections for the local port in question shows that the client
seems to reconnect every two hours. When this happens, the original
connection does not terminate. The programmer on the client side tells me
that he gets a message in his log that the "Remote peer closed the
connection".
So, I guess my next question is this : Are there any defaults that need to
be changed to keep a socket alive? I have searched the web and reviewed the
socket tutorial on your web site, but nothing has really jumped out at me.
BTW, this is what I see using net stat. Note that the remote port 4892
connected four hours ago, then 1469 two hours ago, then 1998 just connected.
Also note that the listening port obviously did something because the idle
time reset. Maybe I need to tweak my server program - it listens, accepts,
and then goes to "TalkToClient" and stays there.
Remote Remote Local
Opt Address Port Port Idle Time State
* * 2575 000:00:05 Listen
10.xxx.x.xxx 1469 2575 002:00:15 Established
10.xxx.x.xxx 1998 2575 000:00:05 Established
10.xxx.x.xxx 4892 2575 004:00:25 Established
Keep in mind that socket programming is new to me and that there may some
very obvious things I am missing - which is why I am asking for help!
I modified the TalkToClient subroutine to go into a endless read (eval
rc = recv(csock: %addr(recbuf):%size(recbuf):0)). My thought being that the
client uses the same connection over and over to pump data to the server and
that the server will sit on the recv statement until there is data to
receive. This appears to be true - until the process is idle for two
hours.
Any thoughts?
Thanks,
Joe
Joe Wells
University of Alabama Health Services Foundation
500 22nd Street South, Suite 308
Birmingham, AL 35233
205-731-5610
CONFIDENTIALITY NOTICE
This e-mail is intended for the sole use of the individual(s) to whom it is
addressed, and may contain information that is privileged, confidential and
exempt from disclosure under applicable law. You are hereby notified that
any dissemination, duplication or distribution of this transmission by
someone other than the intended addressee or its designated agent is
strictly prohibited. If you receive this e-mail in error, please notify me
immediately by replying to this e-mail.
On 10/2/2009 at 4:58 PM, in message
<4AC67773.3010903@xxxxxxxxxxxxxxxx>,
Scott Klement<rpg400-l@xxxxxxxxxxxxxxxx> wrote:
Hello Joe,
As previously mentioned, I have a sockets server program running using
Scott
Klement's SOCKUTIL service program.
Can you be more specific? I wrote lots of different things over the
years that I referred to as "SOCKUTIL". I don't use any of them
anymore.
What does SOCKUTIL do? Are you just using it for FD_SET, FD_ZERO,
FD_ISSET, FD_CLR?
During testing, an issue has come up and I am not sure if it is
"normal" or not. The issue is that I sometimes see multiple
connections from the remote IP. When this happens, the sender
usually tells me that there are documents "stuck" in their outbound
queue. If I kill the program and restart, then I receive the
documents.
How does your server code work? Does it spawn a new job for every
client? Does it multiplex? Does it use INETD?
Here are my questions - Is this a case where I need to follows Scott's
server example that uses "select() for multiplexing"?
Maybe? Maybe not? Not enough information.
Or, is it a case where the sender is stopping and starting their
client and my process is stuck on the first connection. If this is
the case and multiplexing is not the answer, what is the proper way
to handle?
I really don't feel qualified to answer that question at this point.
I'm neither that familiar with your situation, nor that familiar with
what you are already doing now.
Personally, I would avoid multiplexing unless you absolutely need it to
share information between sockets. Such as a chat application. If you
can get by with a spawning application, use that. It's much easier to
write and maintain. (Or use inetd which does the spawning for you.)
For most simple TCP/IP applications, I'd just use inetd.
midrange.com
