proper way to close a socket?
in [MFC]
|
From: Hector Santos on 13 Mar 2010 10:35 Bill, did you see my last posting on this? I posted it twice and they are not showing up. You can dynamic change the timeout and monitor for connect and error using the select() socket command. Example was provided in my last (lost) posting. PS: People, are you seeing some of your postings lost here? Bill Brehm wrote: > Hector, > > Thanks for making me aware of this issue. I didn't know about it before. I > derived from AsyncSocket so once I got things mostly working, I didn't > really go back to see other member functions available and to understand > them. I have looked over the documentation and understand what must be done > and I will do it shortly. > > But do you think this is the cause of my particular crash / assert? In my > case I'm trying to connect to a socket that doesn't exist (for testing > purposes) and want the user to be able to break the connection attempt > without waiting for the 20 second timeout. Since the connection is never > made, there is no chance of data being sent and received so would half > closing the socket from the client side have an affect on the assert that > I'm getting (intermittently)? > > Thanks, > > Bill -- HLS
From: "Bill Brehm" don't want on 14 Mar 2010 10:01 Hector, I see three posts from you on this topic including the one I am answering now. I was away for the weekend but back now and testing these ideas. I added a ShutDown() call before each place that I delete the socket (which again is supposed to also close it for me). The problem is not gone. I see that when I call ShutDown(), I get an error returned that the socket is not connected, WSAENOTCONN. So I guess it's probably not doing what you guys are thinking it will do to solve my problem. I investigated how the DoCallBack() function call works and I see from lParam that when I'm getting the ASSERT, the call would be an OnConnect call with error code WSAENOTSOCK, not a socket. This makes sense since the socket was deleted. To be thorough, I did add the receive() call(s) after the shutdown from Hector's example. I also get a WSAENOTCONN error from that call. Is there something I can do that will act like a shutdown for connects instead of for sends and receives? Am I forced to wait for the connect timeout to occur and therefore cannot abort a connect in progress? Why am I getting the ASSERT sometimes but not all the time? Thanks, Bill "Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message news:exY8BLswKHA.5812(a)TK2MSFTNGP02.phx.gbl... > Bill, did you see my last posting on this? I posted it twice and they are > not showing up. > > You can dynamic change the timeout and monitor for connect and error using > the select() socket command. Example was provided in my last (lost) > posting. > > PS: People, are you seeing some of your postings lost here? > > Bill Brehm wrote: > >> Hector, >> >> Thanks for making me aware of this issue. I didn't know about it before. >> I derived from AsyncSocket so once I got things mostly working, I didn't >> really go back to see other member functions available and to understand >> them. I have looked over the documentation and understand what must be >> done and I will do it shortly. >> >> But do you think this is the cause of my particular crash / assert? In my >> case I'm trying to connect to a socket that doesn't exist (for testing >> purposes) and want the user to be able to break the connection attempt >> without waiting for the 20 second timeout. Since the connection is never >> made, there is no chance of data being sent and received so would half >> closing the socket from the client side have an affect on the assert that >> I'm getting (intermittently)? >> >> Thanks, >> >> Bill > > > > -- > HLS
From: "Bill Brehm" don't want on 17 Mar 2010 21:22 Hector, did my post show up this time? I see it but no one responded, so i'm not sure if others can see it. "Bill Brehm" <don't want spam> wrote in message news:urDZl73wKHA.1692(a)TK2MSFTNGP04.phx.gbl... > Hector, I see three posts from you on this topic including the one I am > answering now. > > I was away for the weekend but back now and testing these ideas. I added a > ShutDown() call before each place that I delete the socket (which again is > supposed to also close it for me). The problem is not gone. I see that > when I call ShutDown(), I get an error returned that the socket is not > connected, WSAENOTCONN. So I guess it's probably not doing what you guys > are thinking it will do to solve my problem. > > I investigated how the DoCallBack() function call works and I see from > lParam that when I'm getting the ASSERT, the call would be an OnConnect > call with error code WSAENOTSOCK, not a socket. This makes sense since the > socket was deleted. > > To be thorough, I did add the receive() call(s) after the shutdown from > Hector's example. I also get a WSAENOTCONN error from that call. > > Is there something I can do that will act like a shutdown for connects > instead of for sends and receives? Am I forced to wait for the connect > timeout to occur and therefore cannot abort a connect in progress? Why am > I getting the ASSERT sometimes but not all the time? > > Thanks, > > Bill > > > "Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message > news:exY8BLswKHA.5812(a)TK2MSFTNGP02.phx.gbl... >> Bill, did you see my last posting on this? I posted it twice and they >> are not showing up. >> >> You can dynamic change the timeout and monitor for connect and error >> using the select() socket command. Example was provided in my last >> (lost) posting. >> >> PS: People, are you seeing some of your postings lost here? >> >> Bill Brehm wrote: >> >>> Hector, >>> >>> Thanks for making me aware of this issue. I didn't know about it before. >>> I derived from AsyncSocket so once I got things mostly working, I didn't >>> really go back to see other member functions available and to understand >>> them. I have looked over the documentation and understand what must be >>> done and I will do it shortly. >>> >>> But do you think this is the cause of my particular crash / assert? In >>> my case I'm trying to connect to a socket that doesn't exist (for >>> testing purposes) and want the user to be able to break the connection >>> attempt without waiting for the 20 second timeout. Since the connection >>> is never made, there is no chance of data being sent and received so >>> would half closing the socket from the client side have an affect on the >>> assert that I'm getting (intermittently)? >>> >>> Thanks, >>> >>> Bill >> >> >> >> -- >> HLS > >
From: Hector Santos on 17 Mar 2010 21:52 Bill Brehm wrote: > Hector, did my post show up this time? I see it but no one responded, so i'm > not sure if others can see it. Before reposting, can you show the code calling the pAsyncSocket->Connect() function? -- HLS
From: "Bill" don't want more on 17 Mar 2010 23:42 Hi Hector, Gladly. Below is the code below, with non-related stuff removed. CMySocket is derived directly from CAsyncSocket. I do not override Create() or Connect() (or any other CAsyncSocket functions), so they pass straight through. My derived class just buffers the data from the stream and returns fully formed strings or packets to the user, depending on the operating mode selected. When the button is pressed, the first time, m_pClientSocket is NULL, so a client socket is new'd, Create()'d and Connect()'d. Next time the button is pressed, the connection will be broken. Before I just deleted the socket, but now I have your ShutDown() recommendation included. I didn't loop the Receive()s because they are giving me a socket not connected error anyway. Notice I have a check if the socket is connected, because I figure I might have to handle the two cases separately. Thanks, Bill void CSocketDlg::OnConnectButton() { // TODO: Add your control notification handler code here if(m_pClientSocket) { if(m_pClientSocket->IsConnected()) { } else { } BOOL ret = m_pClientSocket->ShutDown(2); int error = m_pClientSocket->GetLastError(); char buf[1000]; int bufsize = sizeof(buf); ret = ((CAsyncSocket *)m_pClientSocket)->Receive(buf, bufsize, 0); error = m_pClientSocket->GetLastError(); Sleep(2000); delete m_pClientSocket; // this will also close the connection m_pClientSocket = NULL; } else { CString port; m_toURLCtrl.GetWindowText(m_toURL); m_toPortCtrl.GetWindowText(port); sscanf(port, "%d", &m_toPort); //UpdateData(TRUE); BOOL bRet; m_pClientSocket = new CMySocket; bRet = m_pClientSocket->Create(); if(!bRet) { int error = GetLastError(); } else { m_pClientSocket->SetName("Client Socket"); m_pClientSocket->SetCallbackTarget(this); m_pClientSocket->SetOnAcceptCallback(OnAcceptCallback); m_pClientSocket->SetOnConnectCallback(OnConnectCallback); m_pClientSocket->SetOnCloseCallback(OnCloseCallback); m_pClientSocket->SetOnReceiveCallback(OnReceiveCallback); m_pClientSocket->SetOnSendCallback(OnSendCallback); bRet = m_pClientSocket->Connect(m_toURL, m_toPort); if(!bRet) { int error = GetLastError(); } m_connectCtrl.SetWindowText("Connecting"); } } "Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message news:u9lW72jxKHA.1692(a)TK2MSFTNGP04.phx.gbl... > Bill Brehm wrote: > >> Hector, did my post show up this time? I see it but no one responded, so >> i'm not sure if others can see it. > > > Before reposting, can you show the code calling the > pAsyncSocket->Connect() function? > > > -- > HLS
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 4 5 Prev: typedef struct RTTI/Reflection Next: What is the best way to drive (time) animations? |