Way to store open sockets?

  • Thread starter Thread starter Nash
  • Start date Start date
N

Nash

Hi,
I have a Client and Server application which does communication using
sockets(APM). The problem is Whenever the client is connected to a
server i am storing the socket in a list.

When server wants to send a message to a particular client whose ip is
known, i have to loop through all the sockets in the list, gets its ip
and compare it with my ip and send the data. is there any other way to
avoid looping the huge list??

thanks in advance
 
Nash said:
Hi,
I have a Client and Server application which does communication using
sockets(APM). The problem is Whenever the client is connected to a
server i am storing the socket in a list.

When server wants to send a message to a particular client whose ip is
known, i have to loop through all the sockets in the list, gets its ip
and compare it with my ip and send the data. is there any other way to
avoid looping the huge list??

thanks in advance
Click to expand...

Well, if the IP addresses are unique, then an indexed lookup seems like the
obvious answer. For instance, a simple HashTable where the key is the IP
address and the value is the Socket would work in that case.

HTH,
-rick-
 
As Rick and Michael both suggest, using a hash table to look up the Socket  
instance would work (the Dictionary class uses a hash table).

But it begs the question: why are you in a situation where you know the IP  
address but not the Socket instance?  That's kind of an odd scenario,  
given that it would be much more typical for you to have some more general  
client state data structure that references the Socket directly.  Usually,  
the IP address is simply irrelevant to the higher-level logic.

Pete
Click to expand...

Thank you for answering my question.

Pete to answer your question the scenario is something like this, the
client will connect to the server and send some packet which will have
its IP. The server will store the packet in db and then at its will
reply to the packet received by extracting the packet from DB. hence
server knows the ip to which it responds but not the socket
 
Two problems:

The first is simply that the basic design seems suspect to me.  Granted, I  
don't have all the details, but there should be no reason to store any  
identifying information about the client in the database.  Assuming that  
the same client/server connection is going to be used to reply (and why  
wouldn't it be?), the existing Socket instance should be the frame of  
reference for the reply, and should be maintained alongside whatever  
tracks the other processing in the server, rather than trying to store  
some identification of the client in a database.

The second is that if, in spite of that, you really feel you must track  
your connection by some unique identifier that you'll use later to look up  
the Socket instance, the IP address is absolutely the wrong thing to use, 
because it's not necessarily unique.  Even if you get a true  
Internet-routable IP address, there may be multiple clients using that  
same IP address.  But it's worse than that.  Some clients may be using a  
proxy or NAT router, and be issued a private LAN IP address.  In this  
case, even if you include the port # as part of your "unique identifier", 
you could have duplicates.

Without knowing more about the larger design, I can't explain how to avoid  
this design approach altogether, even though I can strongly encourage you 
to avoid it.  But, if you insist on using the design, you need to pick an  
identifier that is truly unique.  You may find that a 32-bit integer,  
incremented once for each client, is sufficient, but if not you may want  
to use Guids.  In either case, using the client's network address is a bad  
idea.

Pete
Click to expand...

Hi Pete,
My architecture is something like this the communication module will
listen for some incoming packets. when it receives the packet it will
be sent to the db module. DB module will maintain a queue to store all
the packets and will process each packet and send it back to the
communication module which will route it to appropriate client. now
there may be 100 clients connected to the server and may send 100
request. the communication module will no way know which socket it
needs to reply back to the client. so i thought associating ip would
be the best way, but after reading your post i feel i should use GUID
rather than ip to address the issue.

if you have any other option pls let me know. anyway thanks for your
time.
 
Back
Top