more socket questions

more socket questions

• computed_mind

  gotcha.  gotcha.
  
  socket programming really isn't my thing, but i understand the question, and the reference to port 80 for http.  i did some checking and you are right, on the destination machine, doing a netstat -a shows that it has to connections to different ports on my server.
  
  what i am seeing, then, is this:
  
  1.  i send a transaction, which goes to the destination server and waits for a response.
  
  2.  i send another transaction to the destination server.
  
  this second transaction, if i am understanding you correctly, would still go to the same destination port (15100) on the destination server, but just be bound to a different port on my end.  both of them, then, should be waiting for their responses from the destination server on whichever port they used to go out.
  
  when i send one transaction, as soon as the transaction is completed, the netstat -a on the destination server no longer shows my proxy connection. 
  
  when i send two transactions, i see two things. first, as soon as i send the second transaction (while the first one is still processing), my proxy flips out and things that the first transaction completed, even though nothing was returned yet.  the second transaction completes normally.  the second thing i see is that connection for the "failed" transaction, the one that returned to early, still shows up on the destination server.  that is, the netstat -a shows port xxxx TIME_WAIT.
  
  i appreciate you asking the questions that are (hopefully) getting me in the right direction.  i guess now i have to figure out why that first transaction is returning early when another transaction is sent during processing.  (fyi, if i do the same with three transactions, the same thing happens...the first one is "killed" when i send the second transaction, and the second transaction is "killed" when i send the third transaction)
  
  

  
  

• EdgarGustavoPerezGonzalez

  It all depends on how you are implementing the whole thing.

  1. Servers listen on port X and accept client connections. For each client connection, a separate socket is created. The newly created socket then represents a connection to a client. So if 100 clients connect there will be 100 sockets representing connections to the 100 clients.
  2. That said, each of the 100 sockets are bound to a separate port on the server side transparently. The clients should not concern with this. As far as the server goes there are 100 client connections - hence 100 sockets.
  3. Note that at this point the server is actually maintaining 101 sockets. The "first" socket is dedicated to listenig and accepting connections from the clients
  4. Now as far as the clients go each time you connect, you need to create a socket and connect. You could explicitly bind or have the OS choose one for you.
  5. In this excample, presumably there are 100 client sockets ditributed across N machines. Where each machines can have 1 or more client sockets.
  6. What is the server supposed to do
     In this case the server, each time it accepts a connection needs to maintain a collection of client sockets. Then issue async reads or mainatin dedicated threads [async is recommended]. Each time a read succeeds, you would know what socket it is and then send data on THAT SOCKET as your app requires
  7. The client can read and respond as appropriate.
  8. This is a standard model and there are many examples of this model out there.
  9. Also onething you need to know is that if the client closes the connection, then the socket will get a 0 byte read or an exception and you can remove the socket from the list of sockets the server is maintaining.

   

  
  
  

• Nemanja Trifunovic

  My point is that there is no need for the destination server to listen on multiple ports.
  OR I am missing something here

  
  
  

• mbelew

  1.  Got it.
  2.  Got it.
  3.  Got it; on my side, the whole remoting thing handles the listening, and on the destination server, it does its own listening.
  4.  I am using remoting on my proxy server that handles all the client connections, and the only thing i'm really doing on my proxy server is connecting to the destination server, executing the transaction, and returning the response to the client that made the call via remoting.
  5.  ...
  6.  Technically, the remoting stuff should be handling all the client sockets connecting to my proxy server.  The clients make the remote call, which is executed on my proxy server, and I return a response.
  7.  ...
  
  8 & 9
  
  As far as i can tell, the only reason i really need this is because my traffic load is going to be pretty heavy on the proxy server talking to the destination server.  theoretically, i could be executing 1000 or more transactions between my proxy server and the destination server. 
  
  I've found a bunch of examples of asynchronous sockets, and in my architecture, my proxy server is actually a client of the destination server. as far as my proxy server being a server, my assumption is that i am handling that via remoting. 
  
  i've been playing with a number of different samples that i found, but none of them seem to be doing what i think they should be doing.  there is an asynchronous client sample on the msdn site, and a few other ones.  but i still feel like i am missing something which is preventing it from doing what i need.
  
  basically, like i said, i am focused on just the proxy server as a client connecting to the destination server; i'm not concerned about my proxy server accepting incoming client connections because i'm letting the remoting architecture handle all of that. 

  
  

• Utkarsh

  the client uses remoting to connect to my proxy server; there will potentially be 50 or so clients, each of which will have transactions that will need to be processed on the server.
  
  the server itself (not the proxy, which is my application) has defined ports set up on which to listen for transactions.  some of the transactions take milliseconds to complete, some take maybe a minute.  so, the theory is that one transaction is sent on port 15101 and it takes 30 seconds to complete, another transaction can be processed on port 15102, etc. 
  
  so, the proxy server gets a request from a client and finds an available port on the server and executes the transaction. if another client sends another transaction while the first one is still being executed, the proxy should be able to figure out if another port is available or, if not, hang out until a port is available.
  
  i hope that clears up what i am trying to accomplish.  i think i'm running into a problem where my proxy application isn't set up to properly manage the ports on the host machine and there may not be a mechanism by which to do what i am trying to do without managing it myself...if it was a "standalone" always-running application, i think i could more easily manage which port is in use.  like i said, in the serial world, it seems to be pretty straight forward; if the line is in use, its in use. 
  
  

  
  

• DelWare

  You are mixing two scenarios here

  1. The destination server needs to listen on only one port. When a connection is accepted from the proxy server, spawn a thread or use Async operations to make use of the thread pool - and then service the client.

  2. The client which is the proxy server needs to connect to the destination server and send the transacation. The server can then process and send the result back.

  3. In essense the server can have multiple clients without having to listen on multiple ports.Think of how the web server operates. It listens on port 80 but can support thousands of clients

  
  
  
• more socket questions