FacePalm...
After working on my chat application for about a month I came across a problem... A large problem.
My server was allowing clients to connect to themselves!!!
I went through at least 6 different iterations of my server, Simply because if the server is letting clients connect to themselves it must be the serving code right? Well turns out, it wasn't.
I had ported my c++ server/client code to obj-c (just the obj oriented stuff, the base is obviously c) and it worked flawlessly, or so I thought...
--__--
Yesterday I was working away at my client code and I noticed, I had a single compiler warning that I had forgotten to look into (it had been around since I started the project) all it said was:
"implicit declaration of function 'close()'"
hmmm that could be a problem, I thought. So off to google only to find out the 'close' function is in the unistd.h header file, which I had included... or rather 'import'ed
So on a whim, I decided, lets swap the import to an include. And WHAM the whole thing started up perfectly... Every function that I thought should have worked, works. Every iteration of my server works... nearly flawlessly. Weeks of trying to work around a single function... and I'm finally done with my largest bug =)
Ihate Love programming sometimes =)
explanation: The server has a keepalive thread that removes the unconnected sockets, if the sockets are never disconnected... well then any connection can connect to any other connection.
My server was allowing clients to connect to themselves!!!
I went through at least 6 different iterations of my server, Simply because if the server is letting clients connect to themselves it must be the serving code right? Well turns out, it wasn't.
I had ported my c++ server/client code to obj-c (just the obj oriented stuff, the base is obviously c) and it worked flawlessly, or so I thought...
--__--
Yesterday I was working away at my client code and I noticed, I had a single compiler warning that I had forgotten to look into (it had been around since I started the project) all it said was:
"implicit declaration of function 'close()'"
hmmm that could be a problem, I thought. So off to google only to find out the 'close' function is in the unistd.h header file, which I had included... or rather 'import'ed
So on a whim, I decided, lets swap the import to an include. And WHAM the whole thing started up perfectly... Every function that I thought should have worked, works. Every iteration of my server works... nearly flawlessly. Weeks of trying to work around a single function... and I'm finally done with my largest bug =)
I
explanation: The server has a keepalive thread that removes the unconnected sockets, if the sockets are never disconnected... well then any connection can connect to any other connection.
What I love more is how, no matter what language I move to, if there's the possibility for direct memory management then the first debugging I do is a result of buffer overflows. :/
Last edited on
| Yessir =) |
AWESOME!
I'v been seeing you post around about this, and it really would be a bummer if you had too much trouble with this...
magic, as in free beer. haha how do you think?
it involves a simple vector algorithm
it involves a simple vector algorithm
Wait... do you seriously have a huge file full of "banned words"??? Though I suppose I can't come up with a better solution at this time...
EDIT: Free beer... nice :)
EDIT: Free beer... nice :)
Last edited on
It's a dynamic blacklist, users will be able to add to their own blacklists if I feel like adding that functionality.
It's fairly effective, and it doesn't just search for the word,
it will find things such as
{expletive char x}[wildcard*]
x*x*x*x
where the wildcard can be a \n or space or any special character (like underscore) however they must all be the same char, if it gets bad with people trying to get around it, i'll add a temporary ban system.
It's fairly effective, and it doesn't just search for the word,
it will find things such as
{expletive char x}[wildcard*]
x*x*x*x
where the wildcard can be a \n or space or any special character (like underscore) however they must all be the same char, if it gets bad with people trying to get around it, i'll add a temporary ban system.
Clever... you should have a ban option based on votes of no confidence. Just make sure it's not a pack of people going around and banning people. There are ways around this too...
oh it'll be a pretty simple and effective method, think increasing time based ban.
Topic archived. No new replies allowed.