By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,304 Members | 3,172 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,304 IT Pros & Developers. It's quick & easy.

Way to store open sockets?

P: n/a
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
Oct 21 '08 #1
Share this Question
Share on Google+
7 Replies


P: n/a
Nash wrote:
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
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-
Oct 21 '08 #2

P: n/a
"Nash" <je******@gmail.comwrote in message
news:e8**********************************@u40g2000 pru.googlegroups.com...
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
Use a dictionary with the address as the key.

Mike.
Oct 21 '08 #3

P: n/a
On Tue, 21 Oct 2008 02:46:35 -0700, Nash <je******@gmail.comwrote:
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??
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
Oct 21 '08 #4

P: n/a
On Oct 21, 5:45*pm, "Peter Duniho" <NpOeStPe...@nnowslpianmk.com>
wrote:
On Tue, 21 Oct 2008 02:46:35 -0700, Nash <jeevs...@gmail.comwrote:
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??

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
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
Oct 22 '08 #5

P: n/a
On Tue, 21 Oct 2008 20:03:26 -0700, Nash <je******@gmail.comwrote:
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
Oct 22 '08 #6

P: n/a
On Oct 22, 8:22*am, "Peter Duniho" <NpOeStPe...@nnowslpianmk.com>
wrote:
On Tue, 21 Oct 2008 20:03:26 -0700, Nash <jeevs...@gmail.comwrote:
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
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.
Oct 22 '08 #7

P: n/a
On Wed, 22 Oct 2008 03:18:36 -0700, Nash <je******@gmail.comwrote:
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.
I can't offer any specifics without having a code example to demonstrate
exactly the current architecture. But, there's no fundamental reason that
the queue of transactions to handled by the DB module has to be stored in
a database. As long as some client state data structure reference is
passed around with the request itself, then that can be provided back to
the communications module as part of the database response.

Pete
Oct 22 '08 #8

This discussion thread is closed

Replies have been disabled for this discussion.