I'm currently writing a C-based "server", so perhaps I can give an insight
or two...
> -----Original Message-----
> From: Andrew Cartledge [mailto:[log in to unmask]]
[...]
>
> Many many thanks to Lars et al for pointing me at sockets. I
> had visited
> this area in the past but I didn't make much sense then, not
> that it does
> now. Anyway I thought I would try to understand IPC/sockets generally
> before moving onto HTTP on port 80.
As always, a noble plan! There are many good (and far more not-so-good)
books on the subject. One in particular I like is Wrox Press's "Beginning
Linux Programming" (chapter 13 in particular) This chapter takes you,
step-by-step, through building a (single threaded) client & server through a
multi-instance server (via fork) to a multi-threaded server (using
essentially the unix version of NOWAIT I/O) Other people don't like it as
much because, in the step-by-step process, they take you through a couple of
INTENTIONAL "mis-steps" (things like not using "htons()" or "htonl()") to
show you "common pitfalls"
> Using Lars examples I have got a cobol server and a cobol
> client program
> running on my HP. Once an ipcconnect has been made the client
> loops (via a
> counter) in ipcsend n times sending data to the server. The server
> receives data until it encounters a shutdown status (64), in
> which case it
> returns to ipcrecvn or LOGOFF text at which point it closes.
> This works
> fine.
>
> I found that if I run the client program at two terminals at
> the same time,
> the second client is locked out until the first client closes.
The clue to this problem is your last sentance in the previous paragraph:
"...in which case it RETURNS to ipcrecvn..." While I haven't worked with
the cobol example mentioned, nor the "ipc" intrinsics in particular (I'm
using the berkeley sockets methods), I suspect ipcrecvn is equivalent to
"accept()". If so, then this explains why the second client doesn't connect
until the first one dies.
Basically, under the Berkeley sockets interface, accept() is what allows a
NEW connection to be made to the "server". When this call returns, your
program has a new "handle" to a socket "from" the client that just
connected. The system goes back to LISTENING for new connections, however,
any new connections won't be COMPLETED until your program actually calls
"accept()" again -- thus the new connections will "hang".
> OK I thought, I would change the client loop so it restarted
> every time.
> However when I tried this and only running a single client it
> appears to hang after some 61
(ipcdest, connect, recv, shutdown, send, shutdown) loops
I've pulled that line out to highlight it -- in particular, the part about
doing a "shutdown" before doing the "send". It sounds like you're hobbling
your own horse, as they say. If I understand this, you're trying to make
your client act "nice" by only holding the connection open long enough for
one message. Unfortunately, the problem is back at the server, not the
client -- the "server" should be able to manage multiple clients no matter
how much they "hog" the interface.
> and then timesout. An immediate run of the client after
> results in an error
> code 4 (Network error: Transport not initialised).
>
> Can/should two (in this case identical) client processes be
> able to post to
> the same socket at the same time?
> Is the hang/network error a simple case of flooding the
> network with my
> looping program?
I don't think you're neccessarilly "flooding" the network, but you are well
on the way to producing your very own DoS (Denial of Service) "attack" on
your server. Actually, re-reading your original, I take it the client and
server are on the SAME machine, if so, the data isn't really going out onto
"the network" (it may, however, go through the network drivers -- but since
the system would use the "loopback" interface, it doesn't really "hit the
wire", as they say) What you may be "flooding" is your network resources
(number of open/pending connections, for instance) This is stuff buried in
nmmgr screens
|
