Thanks for responding Scott ? my answers to your questions follow your
questions/comments.
Is there any suggested method for which program (socket server vs socket
client) should, preferably be started first?
Server. The client needs something to connect to -- if the server isn't
start, what will the client do? (Flip hamburgers?)
A. Okay - That was my thinking too - just wanted confirmation.
One of our software vendors asks of us as a matter of practice, that
anytime they need to bounce their socket server, I should also, after
their server has restarted, bounce the socket client connections. They
inform us when this is necessary.
By "bounce" do you mean restart? (In computer terms, "bounce" normally
means "reject" or "redirect" such as bouncing an e-mail that's directed to
an invalid e-mail address -- but you seem to be using it differently.)
A. Bounce is a term used by our network people for rebooting ? I use it
liberally to mean shutdown and restart a process.
Now that I have an iSeries RPG socket server program, should I also
consider the same process with my socket clients?
That really depends on how the software is written.
Normally, if you end a server, the TCP connection is closed, which means
that a FIN or RST packet is sent to the remote host (FIN for a nromal
close, RST for an abnormal close). This causes the remote side to get an
error telling them that the connection has closed, and they handle the
situation gracefully.
In the case where you can't send a packet (such as a power failure, cable
ripped out, router explodes, etc) the client program should have a
time-out mechanism so it doesn't sit there indefinitely.
So in a well-written software, the client should detect that it's no
longer connected to the server. Under some circumstances, it makes sense
for write code in the client that re-tries periodically until it's
reconnected -- in that case, you don't need to restart the clients when
the server is restarted, because it'd happen automatically.
A. My socket client programs, thanks to your tutorials do just that! I
coded them to retry x-times and then notify qsysopr if it cannot connect.
It really depends on what the software does and how it's written.
A. The client informed me that his program checks for the server to
connect to every five seconds, and hence he doesn?t need to shutdown and
restart his socket client.
Imagine a scenario where you've written an HTTP server that's available to
the public on the Internet. Everyone in the world can use it. If you
power-cycle it, should you call everyone in the world and tell them to
re-start their browsers? That sure doesn't seem practical!
It really depends on what you're doing. IMHO, in a perfect world, software
should be written so that it's never necessary to manually restart
something like this -- it should be coded for, and should happen
automatically. But, of course, the world isn't perfect.
The reason I ask is, during testing, the connectivity seems a bit flaky,
and I wonder if it's due to the client being connected indefinitely, while
we did end the socket server to do a system save, which afterwards did a
socket client restart.
That doesn't make sense to me. If you end your server, the client
shouldn't be able to stay connected. Therefore, it'll HAVE to be
restarted because it was disconnected. It won't just remain connected and
become flaky!
A. What was ?flaky?, for lack of a better definition was that, during a
debug session, I was able to see detection of a client connection but when
it was waiting to receive data, nothing was coming through the socket ?
even though the client told me he was sending data. That was when I
started to consider the startup/shutdown mentality. I had my socket server
up and running all week, and late Friday afternoon when I asked the client
if they were sending any data, I was informed that they had migrated to
new hardware earlier in the week (that would perform the client task) and
that they had just started to send data. When I tried to shutdown my
socket server, which accepts multiple connections my command to end the
socket server program didn?t get processed either. Long story short is
that by 5:00 Friday we had reestablished connections and were receiving
data, and things seemed to be working as expected.
This project is still in a test environment too and the socket connection
is coming through a vpn tunnel, but that doesn?t have anything to do with
the problems we were experiencing.
I was just wondering if the startup/shutdown process was something that
needed to be ?documented? as SOP in the event that our system operator has
to deal with these kind of issues in the future.
Thanks again for responding. I appreciate your feedback, and your socket
tutorial, your tcp & IFS tutorials and your examples rock!
Regards, Jerry
Gerald Kern - MIS Project Leader
Lotus Notes/Domino Administrator
IBM Certified RPG IV Developer
The Toledo Clinic, Inc.
4235 Secor Road
Toledo, OH 43623-4299
Phone 419-479-5535
gkern@xxxxxxxxxxxxxxxx
This e-mail message, including any attachments, is for the sole use of the
intended recipient(s) and may contain confidential and privileged
information. Any unauthorized use, disclosure or distribution is
prohibited. If you are not the intended recipient, please inform the
sender by reply e-mail and destroy this and all copies of this message.
midrange.com
