vbGore Free Online RPG Engine

Hello people,

I have not posted here in over a year.
I used to be the lead programmer for a period of time for the Drasil project, (though I think many may have claimed that title over the years).

Anyways, I have recently dug up the old vgGore codebase because of one part of it, and one part only... The GORESocket controls.. which are truly a gem for anyone looking to do any sort of multi-client server in VB6...

So, basically since I already felt very comfortable with the codebase surrounding GOREsockets I decided to throw together a sort of demo project/platform to build off of in the future, by mostly copy-pasting, some parts re-writing, a simple chatroom server that can accept multiple connections and relay packets using the fantastic binary packets system included in vbGore..

I started noticing from debugging though that the GoreSOCKETS control is either not cleaning its array properly or I've missed something.
Please see the below screenshot:

Click to Enlarge

I've set up (very cheaply, using a timer, yuck..) a label that basically spits out the state of the server's sockets and some data from the userlist that is used to keep the sockets cleaned and such.. (seen in screenshot).

As you can see above.. even though the 'User_CleanArray' and 'Server_CloseSocket are being called when needed, and although the sockets' states are being converted back to 0 (disconnected), the returned 'inSox' parameter upon connection intermittently seems to increment the 'number of sockets' when not needed.

the confusing part is that this is not always the case, most of the time if you close the client or click the 'disconnect' button everything gets cleaned and the array of sockets gets downsized. It's just if you do it a few times in a row quickly, it eventually starts to build new socket instances onto the array, even though the state of the first sockets in the array DOES get switched to '0' (disconnected) and could be used for a new connection.

I've noticed it happens when the client is terminated prematurely (even though proper shutdown code has been added, aswell as time-out checkers...

Spodi, or anyone else, I was planning on using the sockets platform for a project I wanted to throw together, I'd be willing to pay like $20 for you to take a moment to look over the code and fix this issue, or fix the ocx control if that is where the problem lies.

Here is a link to my code for this 'shell client-server platform' I've been scraping together from vbGore code...
http://www.sakurabranch.com/gore/Code.7z

From what I remember, a lot of vbGORE uses a sort of rolling expansion for the buffers. It keeps track of the last index in use. To add a new entry, you just use lastIndex + 1. When an entry is removed, you check if it was the last index. If it was, it will crawl down until a used index is found.

The purpose of this all is just performance. You get a dynamically sized array that reuses indices, but inserts and removals are still O(1), except for when you remove the highest index, in which case it is O(n).

Now, not saying this is exactly a good idea, its just what I did. But that is why those don't get reused. So if you have 1000 people connect, then everyone but the last one to connect disconnects, then one more connects, they will end up at index 1001, even though 1-999 is free.

Since VB6 doesn't really come with any decent data structures, the easiest fix would be just to start from index 0 and scan until you find a free index (or exceed the bounds of the collection). The scalability would be O(n) instead of O(1), but its not like this check happens often (just once per connection) and the collection doesn't ever get too large, so a linear scan would be fine.

Yea I found the *problem* but not before I had to go to work, it is in the cox control, maybe tomorrow or so I will actually post the function that I believe to be the culprit. The system of deleting the last array elements but not reusing the earlier ones until the last ones are all disconnected, works but didn't work the way i would of wrote it. There is nothing broken about it after some further testing, it just didn't behave how I expected it to.