Click here to Skip to main content
15,913,570 members
Home / Discussions / C / C++ / MFC
   

C / C++ / MFC

 
AnswerRe: firmware coding in C Pin
Richard MacCutchan30-Jan-12 23:37
mveRichard MacCutchan30-Jan-12 23:37 
AnswerRe: firmware coding in C Pin
CPallini31-Jan-12 2:25
mveCPallini31-Jan-12 2:25 
AnswerRe: firmware coding in C Pin
Bram van Kampen31-Jan-12 12:27
Bram van Kampen31-Jan-12 12:27 
AnswerRe: firmware coding in C Pin
Erudite_Eric31-Jan-12 21:05
Erudite_Eric31-Jan-12 21:05 
Question::ifstream.open behaves differently in VC6 and VS2010 Pin
KASR130-Jan-12 22:31
KASR130-Jan-12 22:31 
AnswerRe: ::ifstream.open behaves differently in VC6 and VS2010 Pin
CPallini30-Jan-12 22:42
mveCPallini30-Jan-12 22:42 
GeneralRe: ::ifstream.open behaves differently in VC6 and VS2010 Pin
KASR131-Jan-12 3:24
KASR131-Jan-12 3:24 
AnswerRe: ::ifstream.open behaves differently in VC6 and VS2010 Pin
Albert Holguin31-Jan-12 3:37
professionalAlbert Holguin31-Jan-12 3:37 
GeneralRe: ::ifstream.open behaves differently in VC6 and VS2010 Pin
KASR131-Jan-12 3:42
KASR131-Jan-12 3:42 
AnswerRe: ::ifstream.open behaves differently in VC6 and VS2010 Pin
Albert Holguin31-Jan-12 5:17
professionalAlbert Holguin31-Jan-12 5:17 
GeneralRe: ::ifstream.open behaves differently in VC6 and VS2010 Pin
KASR11-Feb-12 7:29
KASR11-Feb-12 7:29 
Questionbasic Winsock / IOCP / UDP question Pin
SledgeHammer0130-Jan-12 13:01
SledgeHammer0130-Jan-12 13:01 
AnswerRe: basic Winsock / IOCP / UDP question Pin
Jochen Arndt30-Jan-12 22:19
professionalJochen Arndt30-Jan-12 22:19 
GeneralRe: basic Winsock / IOCP / UDP question Pin
SledgeHammer0131-Jan-12 5:01
SledgeHammer0131-Jan-12 5:01 
GeneralRe: basic Winsock / IOCP / UDP question Pin
Jochen Arndt31-Jan-12 5:51
professionalJochen Arndt31-Jan-12 5:51 
GeneralRe: basic Winsock / IOCP / UDP question Pin
SledgeHammer0131-Jan-12 6:27
SledgeHammer0131-Jan-12 6:27 
GeneralRe: basic Winsock / IOCP / UDP question Pin
Jochen Arndt31-Jan-12 6:43
professionalJochen Arndt31-Jan-12 6:43 
GeneralRe: basic Winsock / IOCP / UDP question Pin
SledgeHammer0131-Jan-12 6:58
SledgeHammer0131-Jan-12 6:58 
GeneralRe: basic Winsock / IOCP / UDP question Pin
Jochen Arndt31-Jan-12 7:14
professionalJochen Arndt31-Jan-12 7:14 
GeneralRe: basic Winsock / IOCP / UDP question Pin
SledgeHammer0131-Jan-12 7:19
SledgeHammer0131-Jan-12 7:19 
GeneralRe: basic Winsock / IOCP / UDP question Pin
SledgeHammer0131-Jan-12 14:12
SledgeHammer0131-Jan-12 14:12 
GeneralRe: basic Winsock / IOCP / UDP question Pin
Jochen Arndt31-Jan-12 21:25
professionalJochen Arndt31-Jan-12 21:25 
GeneralRe: basic Winsock / IOCP / UDP question Pin
SledgeHammer011-Feb-12 6:52
SledgeHammer011-Feb-12 6:52 
GeneralRe: basic Winsock / IOCP / UDP question Pin
Jochen Arndt1-Feb-12 7:35
professionalJochen Arndt1-Feb-12 7:35 
GeneralRe: basic Winsock / IOCP / UDP question Pin
SledgeHammer011-Feb-12 7:53
SledgeHammer011-Feb-12 7:53 
Jochen Arndt wrote:
I have never used GetQueuedCompletionStatus(), because blocking
functions may cause problems. E.g. your shut down event will be only processed
after the blocking function returns. If the network connection of the system
drops, this will never occur.


That case is actually handled, although I did not post that snippet Smile | :) . The method that sets the shutdown event also posts an I/O completion message so that it exits the blocking function (copied from MSFT sample code).


Jochen Arndt wrote:
To test your code, you should check the return value of
GetQueuedCompletionStatus(), and test if bytes has been read
(dwBytesTransferred).


Yes, GetQueuedCompletionStatus() returns true and says there are 3 bytes transferred which is correct since the client is sending "0\r\n".

Jochen Arndt wrote:
You should also test your code with only one thread first to ensure that
problems are not sourced by using multiple threads. In your code you are
starting 8 receives in a loop where each uses the same variables. I'm not sure
if that is working.


Yes, for the TCP side of things, this is not an issue because each client is going to new up a CClientContext and get its own buffer.

For the UDP side of things, yes, I understand this will be an issue and that code needs to be refactored / fixed since it will create a CClientContext for the SERVER socket (I just did this to get the code fundamentally going through the same logic flow). Although for now, just testing with a single client sending a single packet Smile | :) .


Jochen Arndt wrote:
WSARecvFrom() does not return the number of bytes reads. It returns
0 upon success. Upon success you should not call GetLastError()
because it returns the most recent error which may be from any previous called
function that fails. Alternatively, you can call SetLastError(0)
before executing a function that may set an error value.


Understood. Just for testing since WSARecvFrom is returning -1. Smile | :) .

For testing again, I set m_nThreadCount to 1, so only 1 worker thread is used. Same issue. dwTransferredBytes = 3. BufferLen = 256, Data is empty. Return value is -1. from is not filled. pOverlapped has everything 0 except the Internal flag which is set to 259.
WSAGetLastError = 997.

I will experiment with your code some more unless you have other ideas?

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.