|
|
Yes, I'm testing <n> clients with server on the same machine. My goal is: if the system works fine on my pc, I will have no problems on server machine.
Is there a minimal example of recv no blocking?
|
|
|
|
|
Did you read the linked page? It is normal a 100% CPU usage if they both run on the same machine.
|
|
|
|
|
If you only have one physical machine, I suggest installing Windows in a virtual machine, and running one of the tasks there. That would ensure that the platforms are separate, and would help you to track down the 100% CPU issue.
IMO, a multithreaded blocking recv() implementation is conceptually much simpler than a non-blocking recv() implementation.
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack.
--Winston Churchill
|
|
|
|
|
Daniel Pfeffer wrote: IMO, a multithreaded blocking recv() implementation is conceptually much simpler than a non-blocking recv() implementation.
Yep, and it works really well... just be careful for hanging sockets in Linux.
Daniel Pfeffer wrote: If you only have one physical machine, I suggest installing Windows in a virtual machine, and running one of the tasks there. That would ensure that the platforms are separate, and would help you to track down the 100% CPU issue.
This might actually yield the same result. The issue is the super low latency in the network when everything is co-located. Essentially if you're tx and rx run as fast as possible, it could take up all the CPU time available.
modified 30-Jun-15 19:41pm.
|
|
|
|
|
Albert Holguin wrote: This might actually yield the same result. The issue is the super low latency in the network when everything is co-located. Essentially if you're tx and rx run as fast as possible, it could take up all the CPU time available
I thought the problem was an optimization in the network stack that gave special treatment to packets sent to the local IP address (127.0.0.1 or the network address). In this case, the data are simply copied to the recv() buffer, without any thread switches etc.
The network drivers provided by the virtual machine monitor may not be optimized to such an extent. While it is possible to detect (and optimize for) packets sent to/from the host O/S, there would be no point in it as the emulation would be less close to a separate machine. I suspect that the virtual machine monitor emulates the physical network card driver, leaving the rest of the network stack untouched.
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack.
--Winston Churchill
|
|
|
|
|
perhaps.... you would really only run into this issue in certain cases (where it would actually be a problem), where the data source isn't throttled and infinite (i.e. mostly test cases)
|
|
|
|
|
CPallini wrote: As far as I know, the server's send is not blocked by the client recv .
They're not, unless they're on the same thread... in which case everything is blocked by the recv().
|
|
|
|
|
Hi
I am getting a return code of 0 from a Create(IDD_DIALOG,dptr); after I created the dialog on the heap CMyDialog *dgtr = new CMyDialog, in the CWinApp and set it to the main windows m_pMainWnd = dgptr;
|
|
|
|
|
The question makes no sense. A modeless dialog is designed to be shown while its owner Window can still accept input and respond to messages. If you want a dialog as your main Window then use a modal type, or some appropriate CView class if using MFC.
|
|
|
|
|
|
Hello.
I am trying to hook winapi for 64 bit apps. I found this example: API Hooking with MS Detours[^]
And I tried to modify BeginRedirect to work with 64 bit programs but every time I inject, my target crashes.
Here's my new code.
#undef UNICODE
#include <windows.h>
#include <cstdio>
#define SIZE 10 //Number of bytes needed to redirect
typedef int (WINAPI *pMessageBoxW)(HWND, LPCWSTR, LPCWSTR, UINT);
int WINAPI MyMessageBoxW(HWND, LPCWSTR, LPCWSTR, UINT);
void BeginRedirect(LPVOID);
pMessageBoxW pOrigMBAddress = NULL;
BYTE oldBytes[SIZE] = {0}; BYTE JMP[SIZE] = {0}; DWORD oldProtect, myProtect = PAGE_EXECUTE_READWRITE; char debugBuffer[128];
INT APIENTRY DllMain(HMODULE hDLL, DWORD Reason, LPVOID Reserved)
{
switch(Reason)
{
case DLL_PROCESS_ATTACH:
MessageBoxW(NULL, L"Attacheds", L"Hooked MBW", MB_ICONEXCLAMATION);
pOrigMBAddress = (pMessageBoxW) GetProcAddress(GetModuleHandle("user32.dll"), "MessageBoxW");
if(pOrigMBAddress != NULL)
BeginRedirect(MyMessageBoxW); break;
case DLL_PROCESS_DETACH:
memcpy(pOrigMBAddress, oldBytes, SIZE);
case DLL_THREAD_ATTACH:
case DLL_THREAD_DETACH:
break;
}
return TRUE;
}
void BeginRedirect(LPVOID newFunction)
{
sprintf_s(debugBuffer, 128, "pOrigMBAddress: %x", pOrigMBAddress);
OutputDebugString(debugBuffer);
BYTE tempJMP[SIZE] = {0xE9, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0xC3}; memcpy(JMP, tempJMP, SIZE); DWORD JMPSize = ((DWORD)newFunction - (DWORD)pOrigMBAddress - 9); VirtualProtect((LPVOID)pOrigMBAddress, SIZE, PAGE_EXECUTE_READWRITE, &oldProtect);
memcpy(oldBytes, pOrigMBAddress, SIZE); sprintf_s(debugBuffer, 128, "Old bytes: %x%x%x%x%x", oldBytes[0], oldBytes[1],
oldBytes[2], oldBytes[3], oldBytes[4], oldBytes[5]);
OutputDebugString(debugBuffer);
memcpy(&JMP[1], &JMPSize, 8); sprintf_s(debugBuffer, 128, "JMP: %x%x%x%x%x", JMP[0], JMP[1],
JMP[2], JMP[3], JMP[4], JMP[5]);
OutputDebugString(debugBuffer);
memcpy(pOrigMBAddress, JMP, SIZE); VirtualProtect((LPVOID)pOrigMBAddress, SIZE, oldProtect, NULL); }
int WINAPI MyMessageBoxW(HWND hWnd, LPCWSTR lpText, LPCWSTR lpCaption, UINT uiType)
{
VirtualProtect((LPVOID)pOrigMBAddress, SIZE, myProtect, NULL); memcpy(pOrigMBAddress, oldBytes, SIZE); MessageBoxW(NULL, L"This should pop up", L"Hooked MBW", MB_ICONEXCLAMATION);
int retValue = MessageBoxW(hWnd, lpText, lpCaption, uiType); memcpy(pOrigMBAddress, JMP, SIZE); VirtualProtect((LPVOID)pOrigMBAddress, SIZE, oldProtect, NULL); return retValue; }
Modified lines are 5, 42, 44, 51. Changes I made are underlined.
Could anyone tell me how to fix it?
|
|
|
|
|
Most likely person to help you is the one who wrote the article and the code. Please post your question in the forum at the end of the article.
|
|
|
|
|
Hello Folks,
Am new to MFC, actually am trying to use PageUp/PageDown keys to switch top/Bottom of the tree, but the problem is when trying am to click keys by default it selects an item & switches over from top-to-bottom/bottom-to-top. And I've also tried the solution
TreeItem = GetSelectedItem();
if (TreeItem)
{
SetItemState(TreeItem, 0, TVIS_SELECTED);
}
but it works when any one of the keys for the second time. so i request for a solution where i can directly switch over from top/button without any item being selected/focused
Thank You,
|
|
|
|
|
Hello,
in a MFC program I've put a picture control (bitmap type) that display a bitmap image inserted into the resources.
I want to draw rectangles on the bitmap so I've put the OnDraw method like this for example:
void CDialog3::OnPaint()
{
CPaintDC dc(this); dc.Rectangle(0,0,300,300);
}
it's very simple and the rectangle has been drawn but it's overlapped by the bitmap when it is drawn in the region where the bitmap is located.
For every rectangle I draw there is the bitmap in front of it.
How can I put the bitmap rear my rectangles and rear any shape that I want to draw?
|
|
|
|
|
You need to understand how controls draw themselves in response to WM_PAINT messages. You probably need to draw the bitmap in the OnPaint method first, and then draw the rectangle over it.
|
|
|
|
|
Dear Richard,
many thanks for your help.
I followed your suggestion and it works.
In my previous code I put the IDB_BITMAP of the bitmap into the IMAGE property of the Picture Control in order to load the bitmap automatically. I hadn't used a control variable to load the bitmap.
Now I have add a control variable and I load the bitmap before drawing the rectangle. In this way the bitmap is under my rectangles.
|
|
|
|
|
I understand that using Hungarian notation is nowadays pretty superfluous , however...
Should I name class variable "cClass" as a class or "oClass" as an object.
Just asking, do not flame me for splitting hair.
Cheers Vaclav
|
|
|
|
|
Vaclav_Sal wrote: Should I name class variable "cClass" as a class or "oClass" as an object. It's completely up to you. What notation helps you to remember what it is?
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
|
|
|
|
|
(hmmmm religious topic, my favorite)
We do not use prefix or suffix (or hungarian notation) for our variable.
class MyClass {};
MyClass myClass;
MyClass* myOtherClass;
I'd rather be phishing!
|
|
|
|
|
The IMPORTANT thing, mY Dear, is_choosing A conVention and USING it ConSiStenTly.
|
|
|
|
|
|
In Windows, you'll see "CClass" a lot (capital C as a prefix)... in Linux and a lot of standard libraries, you won't see any indication at all, for them enclosing things properly within namespaces is more important.
|
|
|
|
|
If you intend to follow the object-oriented paradigm, then prefixing a variable name with 'o' for 'object' makes about as much sense as prefixing it with 'v' for 'variable'. You might still consider this sensible, to visibly discern them from type names, constants, and functions though. YMMV.
As for 'c' (class) prefix, it's often used to distinguish type names from e. g. structs, integral types, enums, etc.. I used (and still use) this a lot, but the longer I think about it the less sense it appears to make: modern editors provide all the information you need by just hovering over the name in question, much more information in fact than you could ever sensibly pack into a prefix. The prefix therefore only carries valuable information if you tend to print out code and prefer analyzing code on paper. Again, not my preference, but YMMV.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
Ok, prefixes for generic objects (like 'o' for objects, or 'v' for variables) are bad notations, but prefixes for variables type make the code more readable, like a story e.g. 'str' for strings, 'n' for numbers, 'arr' for arrays, and so on ... and they are not so hard to type ...
|
|
|
|
|