Re: Sockets server HELP! - repost

Scott,

First of all, thanks again for your help.  (Once again the list comes
through!)  I've been out of the office, and this is the first chance I've
had to let you know what happened.

<SNIP>

I also note this:

       *   ....Receive first 8 bytes of header length
      C            Eval      RC = Recv(I: SocketData@
      C                             : 8: 0)
<SNIP>

Also keep in mind that recv() will return whatever is in the receive
buffer for the socket.   It isn't necessarily 8 bytes long.   It may be
only part of the 8 bytes you need...  you should be either using some sort
of delimiter (usually CR/LF) to determine when a whole message has been
received, or else you should be using a loop to get a fixed length of 8
bytes...   I hope you understand what I mean, as this is a bit too much
to try to fully explain in this message...


The reason I was looking at only 8 bytes is that every message being sent by
the other end has an 8 byte message length header.  I needed to get the
length and then do a second receive for that length.  If not I could get
part of the following message in my receive and get everything out-of-wack.
The messages we are receiving have no CR/LF type EOR delimiters.


 >
 > I remember the second time I looked at your tutorial on-line, I saw that
you
 > had made some changes to your tutorials, and had asked for feedback for
 > improvements.  Maybe a chapter on debugging problems like this, with some
 > detail on how the descriptors should be set before and after function
calls
 > would be helpful.
 >

I haven't even figured out what you're doing wrong, yet :)  But, from the
other questions I've had, it appears that select() does need some more
attention in the tutorial.   I wish I had more time to work on it! :(

As it turns out, the biggest part of my problem wasn't in the server
program, but was being triggered by an error in the client simulator program
we had to write due to not having access to the actual client programs and
systems.  Actually we were pretty much working in a "dark closet" on this
one.

Our client had an internet front end system being developed in the
southwest, their "mid-tier" system was being developed on the east coast,
and the "back end" AS/400 was in the mid west.  We were asked to create a
sockets interface to the AS/400 from the mid-tier system.  At the time we
started this project we had no access to any of the systems, including their
AS/400.  Hence the "dark closet" ;)

Using what little documentation and specs that were available, we created a
server program and a client "simulator" program on our box, as well as the
data.   The simulator took as much programming as the server by the time it
was over.  It had to have the ability to send every type of request message
that the real system would send, and all the fields variable.  It built the
XML type messages and displayed the request message string, including tags
and formatting, before it was sent, and the response message string comming
back.

What happened was that we stopped working on the simulator at some point and
didn't notice a slight error.  This system was supposed to get a connection
on a port from the "client" and keep that connection open to continually
send requests and get back responses. It didn't affect us noticably running
alone on a development box, and so it didn't really show up until we put it
on the production box.  We had accidently included the socket() and
connect() functions of the simulator in the main loop.  So everytime through
it was making another connection and the read set kept growing.  I also had
a problem in the server where I wasn't setting off the socket flags for
receives where I got no data, and the combination was causing the program to
keep looping and never sleep.  The confusing part was that I was looking for
all the problems in the server program, and I couldn't figure out why the
socket #s and descriptors kept going up!  It didn't dawn on me until I put a
bunch of debug code in the server and really looked at it, where the problem
was coming from.

Thanks again for the help.  Much learned on this one!


Jim Whalen
DCS Software and Services
PH 972 429-8238  FAX 972 429-8216
jim.whalen@dcsss.com


_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com