There is no point in using arrays because of memory moving penalty. A linked list will keep about the same amount of memory as a tree, the sole difference would be that finding would be log(n) instead of n. Removing and adding to a linked list is maximum O(n), and to a queue is O(1)
And the memory usage you presume it's still less than 5 % of what you say uhub uses.
Netfraction Inception
-
- Senior Member
- Posts: 328
- Joined: 04 Dec 2007, 07:25
- Location: Bucharest
- Contact:
Re: Netfraction Inception
Just someone
-
- Member
- Posts: 53
- Joined: 15 Sep 2008, 21:48
- Location: adcs://adcs.uhub.org:1511
- Contact:
Re: Netfraction Inception
The memory usage I am objecting to is not the memory required for a full hub, but the wasteful requirement to allocate memory for a hub that is close to empty, or just severely misconfigured.
For a hub with 50 users which is configured to theoretically handle 10000 users (hub owner could be an optimist , that would waste ~1MB of memory for no good reason.
I guess it all just boils down to design issues, although I don't see any compelling reason for choosing this particular one compared to the other ones already outlined.
For a hub with 50 users which is configured to theoretically handle 10000 users (hub owner could be an optimist , that would waste ~1MB of memory for no good reason.
I guess it all just boils down to design issues, although I don't see any compelling reason for choosing this particular one compared to the other ones already outlined.
-
- Senior Member
- Posts: 328
- Joined: 04 Dec 2007, 07:25
- Location: Bucharest
- Contact:
Re: Netfraction Inception
While thinking about this issue, I thought about this: dynamically allocate queue numbers. Keep the queue about the size of the user count and add more to it if there are enough users to get them. One could design this without looking to max user count. ( That could be just a way to keep users from entering )
Just someone
-
- Senior Member
- Posts: 100
- Joined: 30 Dec 2008, 14:59
Re: Netfraction Inception
I think the best reason for using a queue is that the dequeue operation is very cheap on the CPU, and you want the algorithm to be at it's fastest when a user connects and a new SID is needed. The queue operation after the user disconnects is more costly, but at that point who cares? The operation will likely occur in it's own thread, and the length of time to connect a user is vastly more important than the disconnect time.
There is no need to test for collisions with the queue method, only that the queue contains available elements i.e. Queue.Count > 0. Also, the performance of the queue should not vary over the lifetime of the hub. The key disadvantage is all the extra memory allocated which may never be used.
There is no need to test for collisions with the queue method, only that the queue contains available elements i.e. Queue.Count > 0. Also, the performance of the queue should not vary over the lifetime of the hub. The key disadvantage is all the extra memory allocated which may never be used.
-
- Senior Member
- Posts: 328
- Joined: 04 Dec 2007, 07:25
- Location: Bucharest
- Contact:
Re: Netfraction Inception
Which IMHO is very little.The key disadvantage is all the extra memory allocated which may never be used.
Just someone