 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / First Aid / September 2005Sockets!
Hi, I am looking at pros and cons of two approaches. (i) Approach A Client-Servers communicate via sockets The Server keeps two channels one to receive requests(say Port A) and another to send response(Port B). The client after sending the requests waits for the response on the response port (B). The response would contain some header identifying the client. Thus the client and server responses are matched (ii) Approach B Client and Servers use multiple ports. Use Port A for sending requests and based on the port (that client A specifies) when it creates the socket call, teh server uses that port for sending the response. This is the way that i am familiar with but we have a scenario where approach A is proposed. I see lots of adavnatges in B (i) There is no need to match a response with the client. (ii) Bulk of the work is handled by Sockets (iii) Easier to program and maintain (leave teh job to the OS or java.net packages) Because a number of ports are used would that cause a IO overhead when compared to only two ports being used? Appreciate any assistance. Thanks, Manglu To add info the client would be written in Java while the Server would be a c application. I am not familiar with C to be able to state anything but i bleive it should be easy to write both approaches in C. TIA, Manglu > I am looking at pros and cons of two approaches. Two approaches to *what*? > (i) Approach A > Client-Servers communicate via sockets [...] > (ii) Approach B > > Client and Servers use multiple ports. [...] Since you've provided virtually no context for your questions, it is impossible to say much about these two approaches. However you seem to have missed that fact that single socket can be used to communicate in both directions. The server can use one socket per client, and send each response on the *same* socket the request arrived on. Also, because of the way TCP works, all of your sockets can use the *same* port number at the server, and the client port number is not relevant at all. /gordon  Signature[ do not email me copies of your followups ] g o r d o n + n e w s @ b a l d e r 1 3 . s e Gordon, Thanks for your reply. We have a Server written in C and the guy who is writing the server insists that he doesn't want to spawn a thread for every request from us stating that it is inefficient. >From what i read, this is what a lot of servers do. Please correct me if the servers follow a different approach. >From your response, When a client opens a scoket conn. to the server, the server would use the same socket to send a response back to that client call. I understand that the client when it calls the server tells the server to send a response to a port (which is typically chosen by the client). and this port is part of the same socket connection that is created. Is this a correct understanding? Now in Approach B, The Server opens up a scoket connection to the client (in effect the roles are reversed i become the server now). Now i have to look at the message and tie it up to the client thread that had sent the request to the server in the first place. I think this is not a good idea when the server can send the response in the original scoket created by the client. Appreciate your thoughts. Manglu > We have a Server written in C and the guy who is writing the server > insists that he doesn't want to spawn a thread for every request from > us stating that it is inefficient. > > >From what i read, this is what a lot of servers do. Please correct me > if the servers follow a different approach. Many servers spawn a new process or thread for each *client* that contacts it. (Apache Httpd, e.g.) If he's saying he doesn't want to do this then he's a little silly. A good threads implementation should be able to handle many threads without problems. How does he propose handling clients? Sequentially? Sounds like a bad idea to me, but it has its place and you haven't explained much about the application and its environment. |\/| /| |2 |< mehaase(at)gmail(dot)com > We have a Server written in C and the guy who is writing the server > insists that he doesn't want to spawn a thread for every request from > us stating that it is inefficient. > >>From what i read, this is what a lot of servers do. Please correct me > if the servers follow a different approach. That is certainly one way, but many servers written in C handle all clients in a single thread, with select(). The equivalent mechanism in Java is provided by java.nio.channels.Selector. >>From your response, > When a client opens a scoket conn. to the server, the server would use > the same socket to send a response back to that client call. Yes. > I understand that the client when it calls the server tells the > server to send a response to a port (which is typically chosen by > the client). No. When you call someone on the telephone, only *his* telephone number is important, and only while establishing the connection. He doesn't need to call you back to reply, because the initial connection works in *both* directions, Similarly, the server's port number is only interesting while the client is connecting. It is a way for the client to reach the server, and the client's port number is not relevant. Once the connection is established, the port numbers are no longer interesting. The client doesn't need to tell the server where to send the response because the connection consists of two channels, one in each direction. The server can send the response on the same socket that the request arrived on. Do you have any questions related to Java? A more suitable place for this might be comp.protocols.tcp-ip. /gordon Signature[ do not email me copies of your followups ] g o r d o n + n e w s @ b a l d e r 1 3 . s e >The client doesn't need to tell the server where to send the response >because the connection consists of two channels, one in each >direction. The server can send the response on the same socket that >the request arrived on. See http://mindprod.com/jgloss/tcpip.html Look at the packet format. It might become a little clearer. SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Again taking new Java programming contracts. > We have a Server written in C and the guy who is writing the server > insists that he doesn't want to spawn a thread for every request from > us stating that it is inefficient. That's appears to be a clear case of premature optimisation. Probably why the server is written in C in the first place. You don't need a new thread for each job. Threads can be pooled. Similarly processes can be pooled. For processes you would typically have spares all listening on the same server socket. Ball park figures for number of simultaneous connections for each technique are very approximately: hundreds of processes, thousands of threads or tens of thousands using non-blocking or asynchronous I/O. I am confused as to what the advantages of using two ports are. If you open TCP connections you are effectively doubling the workload. However, if you are using UDP then I can understand. Two ports for two parts of the protocol. Broadcasts shouldn't be coming back to the server. Tom Hawtin SignatureUnemployed English Java programmer http://jroller.com/page/tackline/ 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.