Handling connection closure via sockets - how? PopperAndShadow

Handling connection closure via sockets - how? PopperAndShadow

Post by Don Brude » Mon, 27 Dec 2004 05:04:45



Greetings...
Not sure I'm in *PRECISELY* the right place for this question, as a lot
of the posts appear to involve the hardware of networking more than the
software end of things, so if you know a better place for it, feel free
to let me know.

A bit of background that should keep the "tell me more!" questions from
biting me:

I'm attempting, fairly successfully so far, to write what I guess would
best be described as a "sockets compatibility layer" on top of Apple's
OpenTransport networking architecture, to give Pre-MacOS X Macintoshes a
"works exactly like on *nix" sockets API in order to facilitate porting
*nix-targeted program(s) to the Macintosh with minimal (ideally, zero)
alteration to the networking code the program(s) use.

(Please, everybody, spare me the "Just use GUSI" commentary. For
multiple reasons which have no bearing on this question, GUSI isn't
acceptable, nor is attempting to hack it into acceptability acceptable -
As far as myself and this project are concerned, GUSI is a non-starter,
and won't be considered unless I'm left with *ABSOLUTELY NO OTHER*
alternative)

I've got basic functionality in my package - I can socket(), bind(),
connect(), select() (including the relevant FD_* macros), recv(), and
send() successfully on up to 128 discrete sockets using the code I've
hammered together so far, and everything works as expected - To the
point where I can take a raw *nix-targeted source that uses only those
routines, get it to compile by substituting my compatibility code's
headers for <sys/socket.h> and <sys/select.h>, and actually get it to
function mostly as expected.

What I can't do (yet... Here's where you guys and/or gals come in) is
reliably deal with figuring out if/when the socket is disconnected.

How does a "real Unix" program handle the other end sending a disconnect
request?

For instance, if I'm looping on select() to determine if/when there is
data available to be read, I can't figure out how to indicate "The
conenction has been closed by the other end" so that my loop knows to
stop looping and start doing socket shutdown work.

How would a "real Unix" program do this? What would it be looking at to
find out if the connection is still open and there may be more data
coming in? What, if anything, would be set to say "Hey, stupid! The
socket is disconnected!"?

So far, the best I've been able to accomplish is continuing to select()
and/or recv() until the power is cut, which, for obvious reasons, isn't
acceptable.

One attempt that I've made was to add a "connected" flag to the private,
opaque structure that holds info on the socket, and test that, but
that's NOT the way *nix does it - My goal is to be able to port existing
*nix-targeted code to pre-MacOS X Macintoshes *WITH NO MODIFICATION TO
THE NETWORKING CODE*. Besides - Even if it was the way *nix does things,
once that flag is set, all further processing of any data that might be
left in the socket's buffer ceases - Setting "Socket[sd].connected" to
false essentially dumps any buffered-but-not-yet-read data that may be
in the socket's buffer on the floor, which isn't acceptable for quite a
few reasons that should be self-evident.

Any assistance in this department would definitely be appreciated...

I'll be watching this group for responses, or feel free to email me (The
address in the headers is valid) but if replying via email, please be
certain to leave the Subject: line intact - The "(PopperAndShadow)" at
the end is an anti-spammer "password" into my mailbox - Without it,
anything and everything that comes in addressed to me gets sent directly
to /dev/null by my .procmailrc recipes.

--

Short form: I'm trashing EVERY E-mail that doesn't contain a password in the
subject unless it comes from a "whitelisted" (pre-approved by me) address.
See <http://www.sonic.net/~dakidd/main/contact.html> for full details.

 
 
 

1. Q: Sockets - handling multiple connections

I'm trying to write a set of routines to handle server side and client
side socket connections.  I've got most of it down, but now I've run
into a small snag in making the server support multiple clients.
Ok, so immediately after the socket is made, I do a listen, then an
accept, which hangs until a connection is established.  Here's the
accept sequence:

int sk_server_waitforconnect(int sk_fd)
/* Returns a fd to a newly connected socket with blocking */
/*      or negative value if error occurs */
{
        int fd = 0;

        while( (fd = accept(sk_fd, (struct sockaddr *)0, (int *)0)) ==
                                EWOULDBLOCK )
                sleep(SK_WAIT);

        return(fd);

sk_fd, btw is the fd returned from the initial socket() call.
The socket is opened as SOCK_STREAM, btw (which is what I want).  But I
also want to have a function that will basically tell me if another
process wants to communicate on this port.  I've tried a couple things
like accept() without the while loop and using select() but none of
those worked, so I won't bother posting it.

I'd also like a set of routines to say whether or not data is ready
for reading and how much there is to read.  Any hints in this respect
are also quite welcome.

The source might be a little long to post, but if anyone wants to look
at it, I won't mind emailing it.

(I'm a little fuzzy as to whether there is a difference between sockets
and ports, so I use the interchangably.  Sorry if this is incorrect.)

Thanks in advance,
Danny Sung

2. new linux idiot here

3. Opening a socket connection while in a socket connection.

4. regex again

5. Problem with socket closure in 2.2 kernel?

6. File Transfer

7. Problem with socket closure in Linux 2.2 kernel?

8. sb16pnp ide controller.

9. Detecting remote socket closure

10. Robust closure of TCP sockets

11. Socket connections to Windows NT from AIX via Java

12. MSI KT4AV Socket A (Socket 462) VIA KT400A ATX AMD Motherboard & Linux?

13. Weird: get a socket connection without a running socket server !