fingh is correct and using the STL map template makes this a snap!

Dak Lozar
Elysian Productions, Inc.

quote: an Anonymous Poster said:
1. anyone running two nics on the same machine with two routes to the net is crazy anyway, but easily handled. simple force the socket to be bound to a specfic nic. load balancing or not, the packets for that program will only be allowed to travel on that nic and no other nic will see them. that takes care of that problem quickly.

I''m wondering how you deal with a player that is behind a proxy server? Two machines could be connected to the server and be showing the proxies ip address and port. The object id that the server sends to the player when they log in would be the only means of determining _who_ you get the message from... and who your reply to as well. Or am I missing something?



Dak Lozar
Elysian Productions, Inc.

quote: Original post by SmG
i''m currently rewriting it for linked lists, because you can delete one element with one line of code and so the posibility of deleting a player wich is in use is very small.

Whoa whoa whoa. One line of C/C++ code isn''t necessarily one assembly instruction. If you do it this way, you *will* have problems, and they will be incredibly hard to debug.

If you need to lock a structure that multiple threads need to access, use CRITICAL_SECTIONs. If you dont want the contention issues, then find an implementation of a Reader/Writer lock (or write you own). That would allow you to have multiple readers, but only one writer. If you are rarely modifying the structure (acquiring the writer lock), then this can give decent performance.

You should look into the Interlocked* functions in Win32. Using an array/stack combo you can use InterlockedCompareExchange() and it''s brothers to make a fast, contention free* structure.. but you will likely be limited to a certain size (of the array and stack). If you want to write some [x86] assembly, you can write your own Interlocked-like functions (if compatibility on Linux or something is a priority).

* mostly contention free. These functions lock the bus, so if 2 processors are trying to access the same location, then one of them will have to wait, though this "wait" is almost non-existant compared to the cost of a context switch and a transition to kernel mode to grab/wait on a critical section.


-Brannon

To answer the original question of optimizing the lookup from host address to internal data pointer...

For IPv4, the host address is a 32 bit number and the port is another 16 bits -- just use some combination of these values to generate a hash, so that you can quickly store and lookup the associated data. No need for O(n) lookups for each packet.

quote: Original post by Dak Lozar
I''m wondering how you deal with a player that is behind a proxy server? Two machines could be connected to the server and be showing the proxies ip address and port. The object id that the server sends to the player when they log in would be the only means of determining _who_ you get the message from... and who your reply to as well. Or am I missing something?

The ports will be different for each connection coming out of a firewall/proxy server (different for each machine and for each socket). UDP communication across a proxy is well-neigh impossible.

Actually I''m not sure how it works across a firewall (NAT)... I''m alomost certain is does though because I''ve played EQ through a (dynamic) NAT.

Magmai Kai Holmlor

"Oh, like you''ve never written buggy code" - Lee

"What I see is a system that _could do anything - but currently does nothing !" - Anonymous CEO

UDP through a firewall is possible. Most firewalls implement the SOCKS protocol (I forget what it stands for), but basically, the client (that is, the machine behind the firewall) talks to the firewall first, and says "Hey, firewall, any packets coming from that address and going to this address, just let them through, yeah? That''s a good boy." Then it connects to the server, and the server''s packets get through.

Of course, it only works when the machine behind the firewall starts the communication. You can''t get it to work the other way around (cause that''s the whole purpose of a firewall.)

codeka.com - Just click it.