 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / First Aid / August 2007help needed getting unique integer associated with socket
Hello, I am using CORBA with Portable Interceptors in java to intercept a request and find out what client socket it is associated with. This is because the server needs to have a means of uniquely identifying each client. I am not sure how to do this. Using the IP address is not enough since many clients can run on the same machine. So I was wondering is there a way to get the dynamically generated address that the client socket binds to when there is not an an explicit bind? This is not the same as the port number. The port number cannot be used because they are not unique across machines and cannot be combined with the IP address because the answer will not fit in a 4 byte integer. Regards, Andrew Marlow >Hello, > [quoted text clipped - 9 lines] >with the IP address because the answer will not fit in a 4 byte >integer. try hashCode. It may be pretty close to unique. You can assign them yourself in a custom constructor with a simple increment.  SignatureRoedy Green Canadian Mind Products The Java Glossary http://mindprod.com > try hashCode. It may be pretty close to unique. > You can assign them yourself in a custom constructor with a simple > increment. The key words are "may be" and "pretty close to". You can do like the hashed collections do, iterate through a List of items that collide to disambiguate. SignatureLew > On Fri, 10 Aug 2007 09:05:22 -0700, apm35@student.open.ac.uk wrote, > the server needs to have a means of uniquely identifying each > >client. I am not sure how to do this. Using the IP address is not > >enough since many clients can run on the same machine. > try hashCode. It may be pretty close to unique. > You can assign them yourself in a custom constructor with a simple > increment. Pretty close is not good enough unfortunately. I did some investigation into hashCode and found out that IMO it is a poorly named function. It is not a hash code for an IPAddress, it is a unique id to be used when a hash table of IPAddresses has to walk the collision list. So it would provide a way to get a unique id without having to manually generate it from the byte array associated with the IPAddress. But I need more than the IPAddress. Several clients can be running on the same machine so they will all have the same IPAddress. -Andrew Marlow > Pretty close is not good enough unfortunately. I did some > investigation into hashCode and found out that IMO it is a poorly [quoted text clipped - 4 lines] > IPAddress. But I need more than the IPAddress. Several clients can be > running on the same machine so they will all have the same IPAddress. That's all right. The hash code isn't generally unique anyway. hashCode() is named just fine; it does exactly what the name implies, provides a hash code for an object. But you shouldn't think of it as a "unique" anything. The Javadocs make that quite clear. Several clients could be running on different machines and still show the same IP address to the server. Clients on the same machine can show different IP addresses to the server also. So an IP address is not guaranteed to be unique just like hash codes aren't. SignatureLew > > Pretty close is not good enough unfortunately. > That's all right. The hash code isn't generally unique anyway. Well that confirms it. The hashCode is no good for my needs. > Several clients could be running on different machines and still show the same > IP address to the server. Clients on the same machine can show different IP > addresses to the server also. So an IP address is not guaranteed to be unique > just like hash codes aren't. I am hoping that a combination of client-side IP address and client- side port number will be unique for each client. -Andrew Marlow >>> Pretty close is not good enough unfortunately. >> That's all right. The hash code isn't generally unique anyway. > > Well that confirms it. The hashCode is no good for my needs. If you need a unique identifier, the Socket object itself may have to be the identifier, since you cannot tolerate a reduction in the information set size. Note that hash codes work just fine for Map and HashSet to uniquely locate any key. The hash finds the bucket, and a List inside the bucket disambiguates. >> Several clients could be running on different machines and still show the same >> IP address to the server. Clients on the same machine can show different IP [quoted text clipped - 3 lines] > I am hoping that a combination of client-side IP address and client- > side port number will be unique for each client. At any given moment it might be, but you have no way of knowing if two consecutive connections (or consecutive requests if using a stateless protocol) via the same IP:port combination come from one client or different ones. Also, some security software could mask the client port, making every client behind it seem to come from the same port or from some obfuscated port not correlated to the actual client. If you control the network(s) involved and all the firewalls you can compensate for these phenomena. If you are accepting connections from the world you cannot solve these problems using IP address and port. The canonical approach is for the server to create a unique token for the client upon connection and have the client submit it with each request to identify itself. Absence of a token indicates at least a new session, if not a new client. SignatureLew > > I am hoping that a combination of client-side IP address and client- > > side port number will be unique for each client. [quoted text clipped - 3 lines] > protocol) via the same IP:port combination come from one client or different > ones. I am really hoping that this is not the case. Here is how things work in the C++ version right now: once a client connects it is expected sometime later to call the disconnect routine, which will cause the server to lookup the file descriptor asociated with the underlying connection. Once found the item is removed. That way when a new client comes in it might get the same file descriptor allocated and it doesn't matter. Two distinct clients cannot be connected with the same file descriptor at the same time. I am hoping the same applies in the java version when I make it use IP address and port number instead of file descriptor. > Also, some security software could mask the client port, making every > client behind it seem to come from the same port or from some obfuscated port > not correlated to the actual client. Gulp. Well thank goodness this cannot apply in this particular case. But this is useful to know, thanks! I wonder where I can find out more that, just out of curiosity.. > If you control the network(s) involved and all the firewalls you can > compensate for these phenomena. Indeed, and luckily, I can. > The canonical approach is for the server to create a unique token for the > client upon connection and have the client submit it with each request to > identify itself. Absence of a token indicates at least a new session, if not > a new client. Absolutely. And if I had designed the IDL that is what I would have done. I strongly suspect it was done the way it was done to make it much simpler to manage object lifetimes and reference counts. After all what could be simpler than having just one object in the server that lasts forever. Even though I prefer handing back a token this is more coding work. It's a pity it was not done here. Regards, Andrew Marlow > Two distinct clients cannot be connected with the same > file descriptor at the same time. I am hoping the same applies in the > java version when I make it use IP address and port number instead of > file descriptor. For scenarios when you can count on getting the real client port, the key phrase "at the same time" should help you. As long as a client holds a connection, it'll be on the same port. I've just never trusted a black-box extrinsic process like a client acquiring its port to be a source of unique identifiers. There is nothing in that process that makes such a promise. Even the file descriptor approach could be broken if ported to an operating system that worked with some unconventional notion of file I/O. (Not that I know of any such, but why limit the world to my knowledge or imagination?) Lew said: >> Also, some security software could mask the client port, making every >> client behind it seem to come from the same port or from some obfuscated port >> not correlated to the actual client. apm35: > Gulp. Well thank goodness this cannot apply in this particular case. > But this is useful to know, thanks! I wonder where I can find out more > that, just out of curiosity.. I do not know of specific cases. I do know that security software like WebSeal, or really any proxy, makes connections on behalf of the client node. So the connection the server sees is from the proxy, not the "real" client. This is unlikely to be an issue in your case because you don't have a proxy and you are holding connections, not reconnecting for each request. >> If you control the network(s) involved and all the firewalls you can >> compensate for these phenomena. > > Indeed, and luckily, I can. Then your approach will likely work. Very often a solution works in a particular case that has dangers in the general. As long as no one tries to expand the IP:port scheme into the wide area network, you should be all right. The trick is knowing what techniques scale across the firewalls and proxies. SignatureLew > > Two distinct clients cannot be connected with the same > > file descriptor at the same time. I am hoping the same applies in the > > java version when I make it use IP address and port number instead of > > file descriptor. > >> If you control the network(s) involved and all the firewalls you can > >> compensate for these phenomena. > > > > Indeed, and luckily, I can. > > Then your approach will likely work. Phew. > Very often a solution works in a particular case that has dangers in the > general. As long as no one tries to expand the IP:port scheme into the wide > area network, you should be all right. The trick is knowing what techniques > scale across the firewalls and proxies. FWIW, IMO CORBA is broken when it comes to firewalls. I don't think the OMG will ever come up with a workable, implementable specification for a CORBA security service that takes firewalls properly into account. I know they have tried and I know several companies (e.g. ObjectSecurity, 2AB) have tried to get CORBA and security to work. These companies have managed to suceed but I think they have done so in spite of the OMG not because of it. And their solution usually require a particular CORBA implementation that has the necessary extensions for their seurity add-on to work, e.g ObjectSecurity requires MICO. IONA has WonderWall but this requires Orbix. I really like CORBA and think it is under-appreciated by the industry in general, but IMO it is too little, too late for software that has to work in the presence of a firewall and/or over the internet. I think that in those spaces WSDL has emerged as the winner. Regards, Andrew Marlow >I did some >investigation into hashCode and found out that IMO it is a poorly >named function. It is not a hash code for an IPAddress, it is a unique >id to be used when a hash table of IPAddresses has to walk the >collision list. Hash implies some sort of mashing data together with XOR to get a number, 32-bits in this case. There is no guaranteed uniqueness, just that randomness means collisions on the 32 bit are unlikely, though of course collision on the much shorter hash table (say 2047 entries long) are inevitable. You can create a unique number by indexing with the hashCode modulo some prime then breaking the tie by counting the depth on the chain that hash to that slot. SignatureRoedy Green Canadian Mind Products The Java Glossary http://mindprod.com On Aug 10, 12:05 pm, ap...@student.open.ac.uk wrote: >the server needs to have a means of uniquely identifying each client And can this key be assigned sequentially? Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.