|
|
|
G_S wrote: To minimize code execution is there any way to block the IP in the operating system level to minimize code execution since if the attacking IP is allowed to re-connect to the server again it can easily cause a DOS.
The short answer to your question is No. At least, not in the manner you appear to want it. If you want to limit server access, turn on a firewall and security software package (external to your app) that will monitor all ports for such behavior. There is no OS-level APIs to set up this kind of security.
G_S wrote: I could only come up with a globally linked list to hold the IP is there any better way to do this.
Why is the list of "bad" IPs shared with multiple threads?
I would probably use a BST instead of a list, and definately do not make it global. By switching to a BST, you will probably see a significant speed increase. If you absolutely must share it with several threads for whatever reason, you might try using a more complex semaphore to allow as many threads to read it at a given time (so long as no thread is trying to write to it), but only allow 1 writing thread.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
Zac Howland wrote: There is no OS-level APIs to set up this kind of security
This is what I was looking for to block incoming IPs at the OS level.
Zac Howland wrote: Why is the list of "bad" IPs shared with multiple threads?
The list is shared to minimize connection time the connection is accepted a new thread is fired up and the resulting thread checks the “bad” List and also serves the connection.
The number of threads is limited but you get the idea.
thank you for the advice
G_S
|
|
|
|
|
Without knowing the requirements for the application, here is the mostly likely way I would approach the problem, then.
- Create the BST in the main thread, and pass a pointer to it as part of each thread's data (using appropriate protection -- either critical sections or a reading-sempaphore-type setup).
- After Accept is called (spawning the new connection), the thread first checks the BST to see if the IP for the connection is bad. If it is, it closes the connection immediately; if not, it continues on.
You could also use a hash table instead of a BST and have the IP be the key, and a something useful as the value (e.g. the number of failed connections?). This would decrease your searching time even more.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
I'm writing a tiny app that subclasses a window in another process. For this I have a DLL that is injected into the other process by the means of a code>GetMessage hook. So far so good.
Since I'm not interested in the hook itself, on the DLL's DllMain->DLL_ATTACH I call LoadLibrary on the same library to increase it's ref count and then I call UnhookWindowsHookEx to release the hook. After this I subclass the window. At this point everything is fine.
The problem comes when the subclassed window is closed. At this point I want to unload the DLL from memory but I'm at this point unable to do so. The process hangs and is automatically terminated.
What I'm doing is as follows (thanks Emilio_grv!):
LRESULT CALLBACK WndProc(HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM lParam)
{
static unsigned int iRefCount = 1;
++iRefCount;
switch (uMsg)
{
case WM_NCDESTROY:
--iRefCount;
break;
}
--iRefCount;
if (!iRefCount)
{
UnSubclass();
FreeLibrary(m_hInstDLL);
}
return CallWindowProc(lpfnOldProc, hwnd, uMsg, wParam, lParam);
}
Any ideas? 
Thanks !!!!!!!!
|
|
|
|
|
Does lpfnOldProc call into a function that is included in the DLL? If so you need to rearrange the function call to the top and store the return value and return that value at the end.
A cynic is a man who, when he smells flowers, looks around for a coffin.
-H.L. Mencken
|
|
|
|
|
lpfnOldProc is a pointer to the previous window procedure of the subclassed window. I tried that but doesn't make any difference :"(
Thank you for your reply!
|
|
|
|
|
Never call LoadLibrary within DLLMain. Here's a quote from MSDN:
"Warning There are serious limits on what you can do in a DLL entry point. To provide more complex initialization, create an initialization routine for the DLL. You can require applications to call the initialization routine before calling any other routines in the DLL. Alternatively, the initialization routine can create a file with an ACL that restricts access, and each routine in the DLL would call the initialization routine if the file does not exist."
More information can be found here[^], here[^] and here[^].
Steve
|
|
|
|
|
Well, I dropped the LoadLibrary inside DLLMain and instead of calling FreeLibrary on WM_NCDESTROY I'm now calling UnhookWindowsHookEx that solved the problem.
But from what I read in the links you kindly pointed me to, calling LoadLibrary inside DLLMain can only cause deadlocks. The process should freeze, right? but DLLMain completes execution successfully. Besides, I think that's assuming you are loading another library, not just incrementing the same lib's ref counter.
Anyways, that really solved my problem.
Thank you very much, Steve!
|
|
|
|
|
The advice given in the links is clear: don't all LoadLibrary from DllMain. I seen it work before and I've also seen it fail, it would be best to simply follow the rules and not attempt to find conditions when it is safe to break them as such practices are bound to produce a fragile application.
AlexBecker wrote: Besides, I think that's assuming you are loading another library, not just incrementing the same lib's ref counter.
This assumption is not supported by the fact that you shouldn't call GetModuleFileName from DllMain even though it clearly doesn't load anything.
Steve
|
|
|
|
|
I have a MDI application. Views are derived from CFormView.
Now I need scrollbars to scroll the main window when child frames are outside of the CMainFrame client area.
I've enabled scrollbars (EnableScrollBarCtrl) and these are shown but no scroll action is taken (naturally).
Then I've tried to manage the WM_VSCROLL/WM_HSCROLL events, using ScrollWindow and SetScrollInfo. But I've some problems: the content of main window seems to scroll but as soon as I release the scroll bar button the content return to its initial position. And during scrolling the client area is not properly repainted on the bottom side (when scrolling down).
There's a right way to manage scrolling of the main frame window in a MDI application ?
Thanks
|
|
|
|
|
In the settings dialog of the task bar/start menu, there is a setting to enable the "personalized menus", does that setting apply to other application menus ?
Recently, in one of our application, one menu has a small menu item at the botton of the menu to expand and show hidden items, but there is no additional items to show!
What mechanism is used to control that behaviour ? is this a global Windows/Display setting or can this be enabled per application ?
I ask the question because now, using the Dundas bitmap menus, it crashed when selecting the "expand" menu item; before calling them, I want to learn a bit before.
Thanks.
|
|
|
|
|
Hey guys,
I don't see the difference in using two different ways of calling a function.
in the function send, you are creating a pair of set by calling the function creatNVPSet();
In the function update, you are creating a pair of set by first creating a pointer to a Ball object and then using the pointer pBall to call upon the member function createNVPSet();
What's the point of doing that? Can both of the function just create the set by using
createNVPSet(); instead of using pBall->creatNVPSet();
thanks in advance 
PairSet* CreateNVPSet() {
............
............
return set;
}
void send (int x, int y) {
PairSet* pNvpSet = createNVPSet();
................
.............
}
void update (int a, int b) {
Ball *pBall;
PairSet* pNvpSet = pBall->createNVPSet();
...........
........
}
|
|
|
|
|
it's hard to say with the lack of details.
but this is wrong :
Ball *pBall;
PairSet* pNvpSet = pBall->createNVPSet();
you need to create a Ball object before calling createNVPSet on the object, it might simply be a simple omission in your exampel.
Also, you can have more than one method that create the same object, it depends on the design; in your example, does the send function a free function or is it a member of a class ? same thing for update ? maybe in the context of the update function there is no way to create a PairSet except thrue a Ball object.
|
|
|
|
|
sorry im missing some detail. The function createNVPSet is a member of class Ball.
PairSet* Ball::CreateNVPSet() {
............
............
return set;
}
|
|
|
|
|
It isn't calling the same function (at least not directly anyway).
Jay03 wrote: PairSet* CreateNVPSet() {
............
............
return set;
}
This function appears to be in the global namespace and is not a member of any class.
Jay03 wrote: pBall->createNVPSet();
This function is a member function of the class Ball. While it may end up calling the global method within that function, it is not the same function (and may not call the previous one at all ... depending on the implementation).
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
sorry im missing some detail. The function createNVPSet is a member of class Ball.
PairSet* Ball::CreateNVPSet() {
............
............
return set;
}
|
|
|
|
|
Is my initial argument correct now?
|
|
|
|
|
You haven't given enough information to tell, then. Are send and update both member functions as well? Show the whole class and the relevant methods' implementations and it will be easier to answer your question.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
RTI::AttributeHandleValuePairSet* Ball::createNVPSet()
{
RTI::AttributeHandleValuePairSet* pBallAttributes = NULL;
//! Make sure the RTI Ambassador is set.
if ( ms_rtiAmb ) // if ms_rtiAmb!=NULL
{
pBallAttributes = RTI::AttributeSetFactory::create( 4 );
pBallAttributes->add( Ball::ms_ballLocationXId,
(char*)&this->m_currentState.x,
sizeof(double) );
pBallAttributes->add( Ball::ms_ballLocationYId,
(char*)&this->m_currentState.y,
sizeof(double) );
pBallAttributes->add( Ball::ms_ballVelocityXId,
(char*)&this->m_currentState.vx,
sizeof(double) );
pBallAttributes->add( Ball::ms_ballVelocityYId,
(char*)&this->m_currentState.vy,
sizeof(double) );
}
//! pClockAttributes is allocated on the heap and must be
//! deallocated by the calling function
return pBallAttributes;
}
void Ball::sendUpdate()
{
if ( m_nextStateCalculated == RTI::RTI_TRUE )
{
m_currentState = m_nextState;
m_nextStateCalculated = RTI::RTI_FALSE;
try
{
/*!
* In order to send the values of our attributes, we must
* construct an AttributeHandleValuePairSet (AHVPS) which
* is a set comprised of attribute handles, values, and
* the size of the values.
*/
RTI::AttributeHandleValuePairSet* pNvpSet = createNVPSet();
/*!
* Send the AHVPS to the federation.
*
* this call returns an event retraction handle but we
* don't support event retraction so no need to store it.
*/
(void) ms_rtiAmb->updateAttributeValues( getInstanceId(),
*pNvpSet,
NULL );
//! Must free the memory
pNvpSet->empty();
delete pNvpSet;
}
catch ( RTI::Exception& e )
{
cerr << "BALL: Error:" << &e << endl;
}
}
}
void Ball::update(
RTI::InteractionClassHandle theInteraction,
const RTI::ParameterHandleValuePairSet& theParameters )
{
if (ms_rtiAmb) // if ms_rtiAmb!=NULL
{
if ( theInteraction == Ball::ms_clockTickId )
{
RTI::ParameterHandle paramHandle;
RTI::ULong valueLength;
//! We need to iterate through the AttributeHandleValuePairSet
//! to extract each AttributeHandleValuePair. Based on the type
//! specified ( the value returned by getHandle() ) we need to
//! extract the data frlom the buffer that is returned by
//! getValue().
for ( unsigned int i = 0; i < theParameters.size(); i++ )
{
paramHandle = theParameters.getHandle( i );
if ( paramHandle == Ball::ms_clockTickIntervalId )
{
double timeInterval = 1 / 60.0;
theParameters.getValue( i, (char*)&timeInterval, valueLength );
//! Update all clock objects
for ( unsigned int j = 0; j < ms_numInstances; j++ )
{
( *( (Ball*)(ms_instances[j]) ) ).m_stateTimeInterval = timeInterval;
}
}
else if ( paramHandle == Ball::ms_clockTickNumId )
{
//! Don't care
}
else if ( paramHandle == Ball::ms_clockTickTimeId )
{
//! Don't care
}
else
{
//! There must be an error since there should only be
//! one parameter to Communication.
cerr << "BALL: Error: I seem to have received a parameter for "
<< "interaction class ClockTick that I don't "
<< "know about." << endl;
}
}
Ball* pBall;
for ( unsigned int k = 0; k < ms_numInstances; k++ )
{
cout << "BALL: Iterating through all Balls." << endl;
//! Get a pointer to the ball instance
pBall = (Ball*)ms_instances[ k ];
//! ** dequeue state from m_stateQueue and place it in m_currentState
if ( pBall->m_nextStateCalculated == RTI::RTI_TRUE )
{
pBall->m_currentState = pBall->m_nextState;
pBall->m_nextStateCalculated = RTI::RTI_FALSE;
try
{
/*!
* In order to send the values of our attributes, we must
* construct an AttributeHandleValuePairSet (AHVPS) which
* is a set comprised of attribute handles, values, and
* the size of the values. CreateNVPSet() is a method
* defined on the Ball class - it is not part of the RTI.
* Look inside the method to see how to construct an AHVPS
*/
cout << "BALL: Creating NVP set." << endl;
RTI::AttributeHandleValuePairSet* pNvpSet = pBall->createNVPSet();
/*!
* Send the AHVPS to the federation.
*
* this call returns an event retraction handle but we
* don't support event retraction so no need to store it.
*/
cout << "BALL: Sending new ball state out into the world." << endl;
(void) ms_rtiAmb->updateAttributeValues( pBall->getInstanceId(),
*pNvpSet,
NULL );
//! Must free the memory
pNvpSet->empty();
delete pNvpSet;
}
catch ( RTI::Exception& e )
{
cerr << "BALL: Error:" << &e << endl;
}
}
else
{
cerr << "BALL: Next state not ready." << endl;
}
}
}
else
{
cerr << "BALL: Recieved an interaction class I don't know about." << endl;
}
}
}
|
|
|
|
|
As Zac mentioned, show only the relevant code. All that extraneous code just gets in the way. Formatting your code with <pre> tags goes a long way, too.
"Money talks. When my money starts to talk, I get a bill to shut it up." - Frank
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
RTI::AttributeHandleValuePairSet* Ball::createNVPSet()
{
RTI::AttributeHandleValuePairSet* pBallAttributes = NULL;
if ( ms_rtiAmb )
{
pBallAttributes = RTI::AttributeSetFactory::create( 4 );
pBallAttributes->add( Ball::ms_ballLocationXId,
(char*)&this->m_currentState.x,
sizeof(double) );
pBallAttributes->add( Ball::ms_ballLocationYId,
(char*)&this->m_currentState.y,
sizeof(double) );
pBallAttributes->add( Ball::ms_ballVelocityXId,
(char*)&this->m_currentState.vx,
sizeof(double) );
pBallAttributes->add( Ball::ms_ballVelocityYId,
(char*)&this->m_currentState.vy,
sizeof(double) );
}
return pBallAttributes;
}
void Ball::sendUpdate()
{
if ( m_nextStateCalculated == RTI::RTI_TRUE )
{
m_currentState = m_nextState;
m_nextStateCalculated = RTI::RTI_FALSE;
try
{
RTI::AttributeHandleValuePairSet* pNvpSet = createNVPSet();
(void) ms_rtiAmb->updateAttributeValues( getInstanceId(),
*pNvpSet,
NULL );
pNvpSet->empty();
delete pNvpSet;
}
catch ( RTI::Exception& e )
{
cerr << "BALL: Error:" << &e << endl;
}
}
}
void Ball::update(
RTI::InteractionClassHandle theInteraction,
const RTI::ParameterHandleValuePairSet& theParameters )
{
if (ms_rtiAmb)
{
if ( theInteraction == Ball::ms_clockTickId )
{
RTI::ParameterHandle paramHandle;
RTI::ULong valueLength;
for ( unsigned int i = 0; i < theParameters.size(); i++ )
{
paramHandle = theParameters.getHandle( i );
if ( paramHandle == Ball::ms_clockTickIntervalId )
{
double timeInterval = 1 / 60.0;
theParameters.getValue( i, (char*)&timeInterval, valueLength );
for ( unsigned int j = 0; j < ms_numInstances; j++ )
{
( *( (Ball*)(ms_instances[j]) ) ).m_stateTimeInterval = timeInterval;
}
}
else if ( paramHandle == Ball::ms_clockTickNumId )
{
}
else if ( paramHandle == Ball::ms_clockTickTimeId )
{
}
else
{
cerr << "BALL: Error: I seem to have received a parameter for "
<< "interaction class ClockTick that I don't "
<< "know about." << endl;
}
}
Ball* pBall;
for ( unsigned int k = 0; k < ms_numInstances; k++ )
{
cout << "BALL: Iterating through all Balls." << endl;
pBall = (Ball*)ms_instances[ k ];
if ( pBall->m_nextStateCalculated == RTI::RTI_TRUE )
{
pBall->m_currentState = pBall->m_nextState;
pBall->m_nextStateCalculated = RTI::RTI_FALSE;
try
{
cout << "BALL: Creating NVP set." << endl;
RTI::AttributeHandleValuePairSet* pNvpSet = pBall->createNVPSet();
cout << "BALL: Sending new ball state out into the world." << endl;
(void) ms_rtiAmb->updateAttributeValues( pBall->getInstanceId(),
*pNvpSet,
NULL );
pNvpSet->empty();
delete pNvpSet;
}
catch ( RTI::Exception& e )
{
cerr << "BALL: Error:" << &e << endl;
}
}
else
{
cerr << "BALL: Next state not ready." << endl;
}
}
}
else
{
cerr << "BALL: Recieved an interaction class I don't know about." << endl;
}
}
}
|
|
|
|
|
|
it does actually...... does
take away the preprocessor statements
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
