|
|
 |
 |
 |
 |
|
 |
 |
|
 |
 |
|
 |
|
Support::Linux Servers Support forum for Linux EQEMu users. |

09-22-2008, 07:32 AM
|
Developer
|
|
Join Date: Feb 2004
Location: UK
Posts: 1,540
|
|
Quote:
Originally Posted by trevius
|
I've just been looking over the changes to clientlist.cpp in that thread and I think the logic is flawed if that is how you have it coded:
Code:
if (IPInstances > (RuleI(World, MaxClientsPerIP))){
countCLEIPs->SetOnline(CLE_Status_Offline);
iterator.RemoveCurrent();
}
}
countCLEIPs->SetOnline(CLE_Status_Offline);
iterator.RemoveCurrent();
If the code reaches the most deepy nested iterator.RemoveCurrent(), then not only will it it remove the ClientList entry of the connection exceeding the IP limit, but the iterator will be updated to point to the next entry in the ClientList (which probably belongs to someone else), and the flow of execution will then reach the second iterator.RemoveCurrent() and remove that one as well.
My head's hurting from looking at it, so maybe I am misunderstanding the intention of the code.
|
 |
|
 |
 |
|
 |

09-22-2008, 06:29 PM
|
 |
Developer
|
|
Join Date: Aug 2006
Location: USA
Posts: 5,946
|
|
Ya, I do kinda suspect that code could be the cause of the issue. It does actually seem to work the way I want it to from the testing I have done, but I haven't really checked to see what happens if I try to log in more characters than that.
Basically, I want my normal status 0 accounts to be able to log in 3 characters max at once. I then want my status 2 accounts to be able to login a max of 4 characters (1 more character) as a bonus for purchasing my contributor package. Then, I want anything over status 20 to be exempt from the IP limiting. As it is now, the code I have does seem to work to do exactly what I want, but the flaw you mention probably is a real problem. Maybe it is unable to select another client once the first one is removed, so it causes a world crash.
I would definitely be open to better ways of doing this! I know it hurts my head to think about the code for it, but maybe there is a simpler way of getting it done. As suggested in that thread, maybe just having it so that you can set the max number for all clients below X status. Then, for every point higher than that set status it would allow them to have +1 accounts logged in.
Ultimately, I think there needs to be code added (preferably with a rule option) to limit people to only being able to play 1 character per account. Then have the IP Limiting checked after the 1 character per account check happens. So, if someone already has a character logged in that might be ghosted, it will kick them out of the world instead of completely blocking them with IP limiting.
I will keep looking at this code and see if I can make it work better. However, professional help would be appreciated
I am going to try removing this temporarily from my server to see if that resolves my World Disconnect issue. It seems to have started around the same time I added this code in, but I also added alot of other stuff in at that same time, so it is hard to tell. I think this is a likely suspect if no one else is seeing the same exact problem that I currently am.
|
 |
|
 |

09-22-2008, 07:05 PM
|
 |
The PEQ Dude
|
|
Join Date: Apr 2003
Location: -
Posts: 1,988
|
|
Do you have gdb installed? You can use that to parse the core dumps to tell you exactly where in the code the crash occurred.
|
 |
|
 |

09-22-2008, 07:55 PM
|
 |
Developer
|
|
Join Date: Aug 2006
Location: USA
Posts: 5,946
|
|
I just had someone test this on my server. They were able to log in 4 accounts just fine, but when they tried to enter world on the 5th account, it caused the World Disconnect! So, this code is obviously the problem.
Now that I am looking at it again, I see that it is really done pretty badly to begin with lol. The only reason I even stickied the post was because it does include a valid fix for the current IP Limiting code, which is just changing a <= into a < check instead. That minor fix wasn't really breaking anything, but it was definitely making the rule settings misleading.
The custom code I added after that is just custom stuff I am trying to get working properly on my server. I thought it was working right until now and after further testing. I don't think it was actually working quite as I thought to begin with...
This is what I think the IP Limiting code should be doing to work how I would like to see it:
***Optional Additional Feature***
Check if a character is already logged in on this account
If so, then kick the logged in character
If no character is already logged in on this account, then continue
***Optional Additional Feature***
1. Check if there are more connections than the IP limit (MaxClientsPerIP) setting
If not, then allow them to log in.
If so, then continue
2. Check if the Account Status is >= the Additional IP Limit (AddMaxClientsStatus) Setting
If not, then IP Limit them to the IP Limit (MaxClientsPerIP) setting
If so, then continue
3. Check if there are more connections than the Additional IP Limit (AddMaxClientsPerIP) setting
If not, then allow them to log in.
If so, then continue
4. Check if the Account Status is >= the Exempt (ExemptMaxClientsStatus) setting
If not, then IP Limit them to the Additional IP Limit (AddMaxClientsPerIP) setting
If so, then allow them to log in.
Or maybe another way to do it would be:
Check Account Status
- If Status >= Exempt (ExemptMaxClientsStatus), then don't IP Limit
- If Status >= Additional IP Limit (AddMaxClientsStatus) && <= Exempt (ExemptMaxClientsStatus), then IP Limit to the Additional IP Limit (AddMaxClientsPerIP) setting
- If Status < Additional IP Limit (AddMaxClientsStatus), then IP Limit to standard IP Limit (MaxClientsPerIP) setting
I will see if I can figure out the flow of how the code should be to make one of these ways work. Really, I wouldn't mind getting another option in instead of just having a single Additional max clients and status setting. I would like for it to have a setting that just adds 1 more client for every status point over the status setting for these additional account connections.
(Account Status - AddMaxClientStatus + 1) = Total Additional Accounts Allowed Per IP. Of course you would have to check to make sure this is >= 0 otherwise any account below (AddMaxClientStatus - 1) will go into the negative. I will post the code if I figure anything out for it.
Last edited by trevius; 09-23-2008 at 03:57 AM..
|
 |
|
 |

09-22-2008, 09:00 PM
|
Hill Giant
|
|
Join Date: Sep 2007
Posts: 117
|
|
Quote:
Originally Posted by trevius
***Optional Additional Feature***
Check if a character is already logged in on this account
If so, then kick the logged in character
If no character is already logged in on this account, then continue
***Optional Additional Feature***
|
Sorry not trying to derail the thread but
There may be a way to kick the last logged on character for that account without caring if it is logged in.
The account table keeps the name of the last character logged into with that account.
If I get some free time I will see if trying to kick a character that is not logged in causes any crashes/errors.
|
 |
|
 |

09-23-2008, 05:18 AM
|
Developer
|
|
Join Date: Feb 2004
Location: UK
Posts: 1,540
|
|
I tried reorganising the code to work as you originally intended. This is totally untested.
Note that in the case where a connection is removed, I have put a continue; statement which will go back to the top of the while loop, as I don't believe you want to advance the iterator if you've just deleted an element.
Code:
void ClientList::GetCLEIP(int32 iIP) {
ClientListEntry* countCLEIPs = 0;
LinkedListIterator<ClientListEntry*> iterator(clientlist);
int IPInstances = 0;
iterator.Reset();
while(iterator.MoreElements()) {
countCLEIPs = iterator.GetData();
// If the IP matches, and the connection admin status is below the exempt status,
// or exempt status is less than 0 (no-one is exempt)
if ((countCLEIPs->GetIP() == iIP) &&
((countCLEIPs->Admin() < (RuleI(World, ExemptMaxClientsStatus))) ||
(RuleI(World, ExemptMaxClientsStatus) < 0))) {
// Increment the occurences of this IP address
IPInstances++;
// If the number of connections exceeds the lower limit
if (IPInstances > (RuleI(World, MaxClientsPerIP))){
// If the Admin status of the connection is not eligible for the higher limit,
// or there is no higher limit (AddMaxClientStatus<0)
if ((countCLEIPs->Admin() < (RuleI(World, AddMaxClientsStatus)) ||
(RuleI(World, AddMaxClientsStatus) < 0))) {
// Remove the connection
countCLEIPs->SetOnline(CLE_Status_Offline);
iterator.RemoveCurrent();
continue;
}
// else they are eligible for the higher limit, but if they exceed that
else if (IPInstances > RuleI(World, AddMaxClientsPerIP)) {
// Remove the connection
countCLEIPs->SetOnline(CLE_Status_Offline);
iterator.RemoveCurrent();
continue;
}
}
}
iterator.Advance();
}
}
|
 |
|
 |
 |
|
 |

09-23-2008, 05:44 AM
|
 |
Developer
|
|
Join Date: Aug 2006
Location: USA
Posts: 5,946
|
|
Thanks for the post! I have been working on it some too. This is all I have come up with so far:
Code:
//Lieka Edit Begin: Check current CLE Entry IPs against incoming connection
void ClientList::GetCLEIP(int32 iIP) {
ClientListEntry* countCLEIPs = 0;
LinkedListIterator<ClientListEntry*> iterator(clientlist);
int IPInstances = 0;
iterator.Reset();
while(iterator.MoreElements()) {
countCLEIPs = iterator.GetData();
if (countCLEIPs->GetIP() == iIP) {
IPInstances++;
if (IPInstances > (((countCLEIPs->Admin() - (RuleI(World, AddMaxClientsStatus)) + (RuleI(World, MaxClientsPerIP)) + 1) && (RuleI(World, MaxClientsPerIP))) || ((RuleI(World, MaxClientsPerIP)) && (RuleI(World, AddMaxClientsStatus) < 0)))) {
countCLEIPs->SetOnline(CLE_Status_Offline);
iterator.RemoveCurrent();
}
}
iterator.Advance();
}
}
//Lieka Edit End
And, I think this should work for the most part. This stuff hurts my head to think about lol. The only part I still need to figure out is if there is a way to set it to exempt accounts that are above the AddMaxClientsStatus, but still limit them to the total count that they should be set to. The total limit for accounts over the AddMaxClientsStatus should be:
(countCLEIPs->Admin() - (RuleI(World, AddMaxClientsStatus)) + (RuleI(World, MaxClientsPerIP)) + 1)
So, if the account status is 5 and the AddMaxClientsStatus is set to 2 and the MaxClientsPerIP is set to 3, then the equation would look like:
5 - 2 + 3 + 1 = 7
So, they would be able to log in 7 accounts total which is 4 more than all normal accounts below the AddMaxClientsStatus can log in.
Another example is if the account status is 2 and the AddMaxClientsStatus is set to 2 and the MaxClientsPerIP is set to 1, then the equation would look like:
2 - 2 + 1 + 1 = 2
So, they would be able to log in 2 accounts total which is 1 more than all normal accounts below the AddMaxClientsStatus can log in.
The hard part I can't figure out is what happens if they log in multiple accounts all with different statuses on them.... Does it use the highest given account status to define the total of all accounts that can be connected, or does it go on a case by case basis. So, if you log in an account that should be limited to 4 max connections and then log in 3 accounts that are limited to 3 max, will the 4th account be able to login even though it is only individually set to allot 3 max? I am sure that if you log in 3 accounts that should be limited to 3 max and then log in a 4th that is limited to 4 max, the 4th should be able to connect without a problem.
I will test this out and report back lol. I don't think not knowing how to program is helping me, but I think the worst part is figuring out the logic of the flow process it should be using and how to handle every possible scenario :P
Last edited by trevius; 09-23-2008 at 03:12 PM..
|
 |
|
 |
Thread Tools |
|
Display Modes |
Hybrid Mode
|
Posting Rules
|
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
HTML code is Off
|
|
|
All times are GMT -4. The time now is 07:00 AM.
|
|
 |
|
 |
|
|
|
 |
|
 |
|
 |