|
the reviews for it were all good too but i just wanted to make sure. thanks guys. I feel a little stupid now i didnt realize it was so popular. i wouldnt have asked if i knew it was like asking if scott meyers was worth buying.
|
|
|
|
|
markt wrote: scott meyers was worth buying
His stl book is also pretty good
|
|
|
|
|
I'm using CAsyncSocket::OnReceive() to receive data at rates above 5Mbps (100+ packets per second) and it appears that Windows is dropping some of the data. Here's my test setup:
Two computers connected to a hub both with 100Mbps connections and no other devices attached.
PC1 - sending 10,000 1.3k UDP packets @ 5Mbps
PC2 - receives ~9700 1.3k UDP packets
Now the weird thing is when WireShark is running on PC2 WireShark captures all 10,000 1.3 k UDP packets. So i know the data is making it to PC2, but don't know why my app that's using CAsyncSockets::OnReceive( ) can't seem to get all the data.
Anyone have any ideas? Is this possible a Windows messaging limitation? Any insight would be greatly apprceiated.
Thanks
Earnest
|
|
|
|
|
What are you doing in OnReceive?
You should be looping there (calling recv()/Receive()/ReceiveFrom()) until all the datagrams
available have been received.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Here's basicly my OnReceive() routine minus some error checking:
void CMyAsyncSocket::OnReceive(int nErrorCode)
{
int BytesIn;
BytesIn = ReceiveFrom(Buff, BuffSize, SenderAdd, SenderPrt);
PacketsRcvd++;
CAsyncSocket::OnReceive(nErrorCode);
}
|
|
|
|
|
|
Always check socket error codes!
Maybe something like this (assuming all your UDP socket creation is correct/successful, buffer and
packet count variables initialized properly) ...
void CMyAsyncSocket::OnReceive(int nErrorCode)
{
<font color="Green">
while (1)
{
int BytesIn = ReceiveFrom(Buff, BuffSize, SenderAdd, SenderPrt);
if (0 == BytesIn)
{
<font color="Green">
return;
}
else if (SOCKET_ERROR == BytesIn)
{
DWORD errcode = GetLastError();
if (WSAEWOULDBLOCK == errcode)
{
<font color="Green">
return;
}
else
{
<font color="Green">
return;
}
}
<font color="Green">
PacketsRcvd++;
<font color="Green">
}
}
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
So basicly i'm just missing a WHILE loop. I thought about using one but figured windows had to "notify" the OnReceive callback inorder to continually iterate through the routine.
Well I'll give it a shot. Thanks so much for you help.
Cheers!
Earnest
|
|
|
|
|
|
By the way, you don't HAVE to use the loop....if you don't loop, and there's more datagrams ready to be received,
then another FD_READ will be triggered, eventually causing another OnReceive() call.
But think about what that does to the hidden CAsyncSocket event window's message queue at that data rate
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
i used CAsyncSocket and CSocket, the applications missed some data. Then, changed to WinSock and everything is working fine. I too suggest Winsock.
|
|
|
|
|
Hello all,
I remember a time when I would have answered this question but alas... memory is failing me...
I am using a WH_CALLWNDPROC hook procedure to add a menu item in a context menu I don't own.
InsertMenu(menu,0,MF_BYPOSITION|MF_STRING,IDM_MYITEM,"Menu Item");
Where IDM_MYITEM is defined as 500.
The item is being added and when clicked a command is fired...
However when I capture the WM_COMMAND message the IDM_MYITEM value is nowhere to be found in the wParam of the message. What am I missing?
Thank you in advance for your response
Alberto Bar-Noy
Project Manager
http://www.consist.co.il
|
|
|
|
|
Alberto Bar-Noy wrote: ...the IDM_MYITEM value is nowhere to be found in the wParam of the message.
How are you verifying this?
"Normal is getting dressed in clothes that you buy for work and driving through traffic in a car that you are still paying for, in order to get to the job you need to pay for the clothes and the car and the house you leave vacant all day so you can afford to live in it." - Ellen Goodman
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
I am checking the LOWORD of the wParam where according to documentation the menu item identifier should be...
Alberto Bar-Noy
Project Manager
http://www.consist.co.il
|
|
|
|
|
Hi All!
just wanted to ask, if i have a function which expects a LPCTSTR.. is it ok to call it as shown below
func(LPCTSTR lp)
{
....
}
1) CString str="something";
func(str);
2) LPWSTR str="something"; <-- just a sample, not sure how to set a LPWSTR type
func((LPCTSTR)str);
thanks!
me
|
|
|
|
|
ginjikun wrote: is it ok to call it as shown below
Coding schemes aside, yes. If it wasn't, the compiler would surely complain.
"Normal is getting dressed in clothes that you buy for work and driving through traffic in a car that you are still paying for, in order to get to the job you need to pay for the clothes and the car and the house you leave vacant all day so you can afford to live in it." - Ellen Goodman
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
1) one is OK.
2) is bad, since it will work only on UNICODE builds. it is better:
LPTSTR str = _T("something");
func(str);
BTW: The L prefix does the magic for wide character literals, for instance
LPWSTR str = L"something"
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
|
|
|
|
|
Hi, thanks for the reply!
the assignment is just a sample.. however i am more concern with how FUNC is being called. you mentioned it will work only on UNICODE. what if the project is compiled with _MBCS, will FUNC((LPCTSTR)str) still work?
thanks!
me
|
|
|
|
|
if you define _MBCS instead of _UNICODE then FUNC((LPCTSTR)str) expects const char * but you're passing instead a
const wchar_t * . the pointer types are quite different and you're forcing the latter into the former with static cast, i.e. mistake.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
|
|
|
|
|
Hi, thanks again.
since it is an mfc project i just cast it to CString instead.
func((CString)LPWSTR)
i think this should be ok... ???
me
|
|
|
|
|
ginjikun wrote: i think this should be ok... ???
That works thanks to temporary CString object's constructor
(it perforforms the conversion).
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
|
|
|
|
|
ginjikun wrote: 1) CString str="something";
func(str);
ok.
ginjikun wrote: 2) LPWSTR str="something"; <-- just a sample, not sure how to set a LPWSTR type
LPWSTR str = L"something";
LPCWSTR str = L"something";
ginjikun wrote: func((LPCTSTR)str);
requires care. in this case if your project is unicode, it is safe.
|
|
|
|
|
hi Rajkumar R, what if the project is compile with _MBCS? will it still be ok?
thanks
|
|
|
|
|
No, it is not ok. My previous statements is still correct.
func((LPCTSTR)str);
requires care. in this case if your project is unicode, it is safe.
ginjikun wrote: what if the project is compile with _MBCS? will it still be ok?
with the project settings, whenever the LPCTSTR is defined as LPCWSTR it is safe, as the str is of type LPWSTR. AFAIK, MBCS is not wide character, so passing wide character to function taking MBCS is not safe.
mostly, Wide character and single character is used without any precautions simply using generic text mapping functions, but MBCS requires additional handling like (You must keep track of which bytes are lead bytes).
|
|
|
|
|