IS there any way knowing that r u connected to remote socket or not ?

[Metal2]

Hi all,

I m creating a socket like this and receiving remote socket

CScoket rConnectedSocket ;
CScoket * pSrvSocket;
pSrvSocket = new CSocket();
ASSERT_VALID(pSrvSocket);
pSrvSocket->Create(Agent_Port);
pSrvSocket->Listen();
pSrvSocket->Accept(rConnectedSocket);

..............
.............
...................

pSocketFile = new CSocketFile(&rConnectedSocket);

pArchiveIn = new CArchive(pSocketFile, CArchive::load);
pArchiveOut = new CArchive(pSocketFile, CArchive::store);


now later in code is there any way that I could know that I m still connected to remote socket or not ?

Thanks
METAL

[ahoodin]

Allright, good question, especially if you are not sending data at the time. People use what are known as keep alive packets in standard C Sockets API. This means that there is a built in mechanism to check this, not really sure how to implement this in MFC Sockets, however I can tell you that you need to do a SetSockOpt with SO_KEEPALIVE.

HTH,

ahoodin

[Marc G]

[ moved thread ]

[MikeAThon]

...now later in code is there any way that I could know that I m still connected to remote socket or not ?

The standard technique is simply to send a pre-arranged request out to the remote socket, and check on whether the remote socket responds in the expected way. The nature of the "pre-arranged request" and the "expected response" is entirely up to you, and you should code whatever you want.

If you do not have access to code for the remote socket, then the task is more difficult. The "keep-alive" packet mentioned by ahoodin is normally of only little assistance, since the time-interval between packets defaults to something like 2 hours.

Mike

[ahoodin]

The "keep-alive" packet mentioned by ahoodin is normally of only little assistance, since the time-interval between packets defaults to something like 2 hours.
Mike

You know Mike it is an option so quit being so negative. Your being negative again Mike! I know this because there is no standard on the matter. You can set the SO_KEEPALIVE timeout in the registry.

Windows 98
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\MSTCP

Windows NT/2000
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\TCPIP\Parameters

OR You can do it with code.


WORD w = MAKEWORD(2,2);
WSADATA wsadata;
WSAStartup(w, &wsadata);
SOCKET s = socket(AF_INET, SOCK_STREAM, 0);

int optval = true;
int err = setsockopt( s
, SOL_SOCKET
, SO_KEEPALIVE
, (char*)&optval
, sizeof(optval)
);
err = setsockopt( s
, IPPROTO_TCP
, TCP_NODELAY
, (char*)&optval
, sizeof(optval)
);

[MikeAThon]

You know Mike it is an option so quit being so negative. Your being negative again Mike! I know this because there is no standard on the matter. You can set the SO_KEEPALIVE timeout in the registry...
All I said was that keep-alive is "normally of only little assistance". I think that's fair. And, the Winsock FAQ says pretty much the same thing: see http://tangentsoft.net/wskfaq/newbie.html#abnormalclose
Another option you should not bother with is the TCP keepalive mechanism. This is a way to tell the stack to send a packet out over the connection at specific intervals whether there's real data to send or not. If the remote host is up, it will send back a similar reply packet. If the TCP connection is no longer valid (e.g. the remote host has rebooted since the last keepalive), the remote host will send back a reset packet, killing the local host's connection. If the remote host is down, the local host's TCP stack will time out waiting for the reply and kill the connection.

There are two problems with keepalives:

Only Windows 2000 and its successors allow you to change the keepalive time on a per-process basis. On older versions of Windows, changing the keepalive time changes it for all applications on the machine that use keepalives. (Changing the keepalive time is almost a necessity since the default is 2 hours.)

Each keepalive packet is 40 bytes of more-or-less useless data, and there's one sent each direction as long as the connection remains valid. Contrast this with a command/response type of protocol, where there is effectively no useless data: all packets are meaningful. In fairness, however, TCP keepalives are less wasteful on Windows 2000 and its successors than the "are you still there" strategy above.

Mike