 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / January 2006The beauty of TCP/IP
I was thinking about a pleasing feature of TCP/IP. The throughput does not depend on how many hops it takes to get to you. It depends on the speed of the slowest hop, which would normally be the one next to you or next to the server. TCP/IP is like a very long train of packets with many in flight at once. There is no fixed path for packets. A highspeed middle link could be the bottleneck if it were the most congested. On the other hand if you send a datagram and send a datagram in return, the response time depends on the number of hops. So even though the Internet is designed at the fundamental level around delivery of individual packets, it is most efficient when delivering streams.  SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. >I was thinking about a pleasing feature of TCP/IP. > [quoted text clipped - 13 lines] > around delivery of individual packets, it is most efficient when > delivering streams. Yes - now come up with a way for me to explain to my grandma the difference between latency and throughput - because thus far people just don't get it. SignatureLTP :) On Fri, 23 Dec 2005 15:50:08 -0700, "Luc The Perverse" <sll_noSpamlicious_z_XXX_m@cc.usu.edu> wrote, quoted or indirectly quoted someone who said : >Yes - now come up with a way for me to explain to my grandma the difference >between latency and throughput - because thus far people just don't get it. The difference between one guy with a bucket and a bucket brigade. The bucket does not get there much faster by brigade, but more buckets per minute do. SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. > On Fri, 23 Dec 2005 15:50:08 -0700, "Luc The Perverse" > <sll_noSpamlicious_z_XXX_m@cc.usu.edu> wrote, quoted or indirectly [quoted text clipped - 8 lines] > bucket does not get there much faster by brigade, but more buckets per > minute do. Ah thanks - that works well. -- LTP :) > Yes - now come up with a way for me to explain to my grandma the difference > between latency and throughput - because thus far people just don't get it. The difference between a truckload of tapes and a modem. The truck has high bandwidth, long latency, the modem has low bandwidth, short latency. >> Yes - now come up with a way for me to explain to my grandma the >> difference between latency and throughput - because thus far people just >> don't get it. > > The difference between a truckload of tapes and a modem. The truck has > high bandwidth, long latency, the modem has low bandwidth, short latency. While I appreciate your effort - I have more faith in the bucket brigade idea :) Maybe it's just cause I know my grandma. -- LTP :) On Tue, 27 Dec 2005 03:04:49 -0700, "Luc The Perverse" <sll_noSpamlicious_z_XXX_m@cc.usu.edu> wrote, quoted or indirectly quoted someone who said : >While I appreciate your effort - I have more faith in the bucket brigade >idea :) Maybe it's just cause I know my grandma. Why does Grandma want to know this? SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. > On Tue, 27 Dec 2005 03:04:49 -0700, "Luc The Perverse" > <sll_noSpamlicious_z_XXX_m@cc.usu.edu> wrote, quoted or indirectly [quoted text clipped - 4 lines] > > Why does Grandma want to know this? She doesn't - she was never interested, and that is likely why she just couldn't grasp it. It came up once a long time ago in a conversation with her. The question has come up multiple times though; I remember once trying to explain to a friend why a modem might be superior to a satelite connection for playing games. I got through to him, but it was harder than I expected it to be to explain. The concept seems intuitive to me, so it is my belief that an example to which someone can relate should aid in making it intuitive to other people. SignatureLTP :) > On the other hand if you send a datagram and send a datagram in > return, the response time depends on the number of hops. Not really. Datagrams are routed the same way as TCP segments, so consecutive datagrams can take different paths through the network, just as TCP segments can. On Tue, 27 Dec 2005 08:26:24 GMT, "E.J. Pitt" <esmond.not.pitt@not.bigpond.com> wrote, quoted or indirectly quoted someone who said : >> On the other hand if you send a datagram and send a datagram in >> return, the response time depends on the number of hops. > >Not really. Datagrams are routed the same way as TCP segments, so >consecutive datagrams can take different paths through the network, just >as TCP segments can. Even if each packet goes a different route, by slightly different numbers of hops, the round trip time for the entire packet bundle depends on the number of hops and the time of each hop, or more precisely the case for the worst subpacket. SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. >>>On the other hand if you send a datagram and send a datagram in >>>return, the response time depends on the number of hops. [quoted text clipped - 7 lines] > depends on the number of hops and the time of each hop, or more > precisely the case for the worst subpacket. (a) Subpackets have nothing to do with it. A fragemented UDP datagram will never be reassembled. (b) Even if it was, why is this different from TCP/IP? RTT depends on the total latency between endpoints. It doesn't really depend on the number of hops, just one hop with a large latency will mostly determine the RTT. On Wed, 28 Dec 2005 08:20:04 GMT, "E.J. Pitt" <esmond.not.pitt@not.bigpond.com> wrote, quoted or indirectly quoted someone who said : >(b) Even if it was, why is this different from TCP/IP? RTT depends on >the total latency between endpoints. It doesn't really depend on the >number of hops, just one hop with a large latency will mostly determine >the RTT. Performance in TCP/IP depends on throughput, packets per second arriving. That roughly depends on the time to traverse the worst hop. One hop becomes the bottleneck in the train. Speeding up the other hops won't help, same a traffic. So, oddly, having many hops won't necessarily hurt performance. Performance in UDP depends on end-to-end time. It is the sum of all the hops. The more hops you have the slower it will be. Here is a typical local tracert: 1 <10 ms <10 ms <10 ms router [192.168.0.1] 2 43 ms 23 ms 23 ms shawgateway [24.69.120.1] 3 25 ms 23 ms 23 ms rd1cv-ge3-1-2.gv.shawcable.net [64.59.166.98] 4 27 ms 24 ms 23 ms rd2cv-pos0-0.gv.shawcable.net [66.163.72.1] 5 27 ms 29 ms 30 ms rc1wt-pos2-1.wa.shawcable.net [66.163.77.21] 6 28 ms 29 ms 29 ms rc2wt-pos1-0.wa.shawcable.net [66.163.68.2] 7 27 ms 29 ms 29 ms rx0wt-abovenet.wa.shawcable.net [66.163.68.22] 8 29 ms 29 ms 30 ms 209.249.11.173.data-fortress.com [209.249.11.173 ] 9 31 ms 35 ms 29 ms a.cust.65-110-0-2.van.data-fortress.com [65.110. 0.2] 10 43 ms 38 ms 34 ms mindprod.com [65.110.20.44] SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. > Performance in TCP/IP depends on throughput, packets per second > arriving. That roughly depends on the time to traverse the worst hop. [quoted text clipped - 4 lines] > Performance in UDP depends on end-to-end time. It is the sum of all > the hops. The more hops you have the slower it will be. I'm sorry, I still don't understand what the difference you are talking about actually is. Performance *is* throughput, surely? bytes per second? and surely this is a linear function of delay at each hop and number of hops? in both cases? On Thu, 29 Dec 2005 08:18:04 GMT, "E.J. Pitt" <esmond.not.pitt@not.bigpond.com> wrote, quoted or indirectly quoted someone who said : >I'm sorry, I still don't understand what the difference you are talking >about actually is. Performance *is* throughput, surely? bytes per >second? and surely this is a linear function of delay at each hop and >number of hops? in both cases? No. Let me try once again. What counts with TCP/IP doing a long file download is how many bytes per second come through the spigot. If would not matter if each individual packet took 60 seconds to wend its way through the packet net. Thus the number of hops is not critical. What is critical is the bottleneck hop. (which varies since packets don't take the precise same route). The response time of the server is not critical either, so long as it can keep the pipeline filled. For a Datagram, what counts is the round trip time for one packet to make it to the server and for a response to be formulated and a packet send back. Thus every hop is critical, and the number of hops are critical. SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. > No. Let me try once again. What counts with TCP/IP doing a long file > download is how many bytes per second come through the spigot. If [quoted text clipped - 8 lines] > send back. Thus every hop is critical, and the number of hops are > critical. So you are comparing apples and oranges: bandwidth in TCP and latency in UDP. So? I also don't see how this justifies your original statements that the Internet 'is most efficient when delivering streams' or that the number of hops is the critical element in UDP timings. > So you are comparing apples and oranges: bandwidth in TCP and latency in > UDP. So? > > I also don't see how this justifies your original statements that the > Internet 'is most efficient when delivering streams' or that the number > of hops is the critical element in UDP timings. It was phrased in a confusing way. However, I'd agree that the Internet is most efficient when delivering "streams"... that is, when delivering large amounts of one-way data whose transfer time with the available bandwidth dwarfs the communication latency. Whether these streams are delivered via TCP or UDP is, of course, pretty much irrelevant to the fact being discussed. I think that's led to a little confusion here. I think Roedy's logic is that streams of large amounts of data are most likely to be done via TCP rather than UDP, and therefore there exists some correlation between TCP and more efficient applications. I'm not so sure that correlation is real, though. Downloading of FILES for local storage and later use would be done with TCP. However, online viewing of real-time media such as video or audio is more commonly done with UDP (and, confusingly, in a way that's also known as "streaming") because a late packet is no good... if I miss a frame of the video, that's fine; and I don't want to delay the receipt of the later frames until the server can retransmit that frame that was missed. Hence, streaming live audio/video is a counterexample to pushing this into the TCP/UDP division. Signaturewww.designacourse.com The Easiest Way To Train Anyone... Anywhere. Chris Smith - Lead Software Developer/Technical Trainer MindIQ Corporation >I think Roedy's logic is that streams of large amounts of data are most >likely to be done via TCP rather than UDP, and therefore there exists >some correlation between TCP and more efficient applications I was not trying to make any such statement. I was trying to point out that UDP and TCP/IP stream performance depend on different characteristics of the connection. Either you have a continuous stream of data or you have intermittent packets. Even if you were to use TCP/IP for exchanging intermittent packets, it will behave from a performance point of view like UDP. I thought I was stating something almost too obvious to mention, but apparently it is not. SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. I wrote: > >I think Roedy's logic is that streams of large amounts of data are most > >likely to be done via TCP rather than UDP, and therefore there exists > >some correlation between TCP and more efficient applications > I was not trying to make any such statement. I'm still not convinced. You say you're not making any such statement, yet you go on to make such a statement. > I was trying to point > out that UDP and TCP/IP stream performance depend on different > characteristics of the connection. But they don't. Both UDP and TCP have latency and bandwidth. Latency depends on the sum of the processing at each node and communication times between hops, and bandwidth depends on the width of the narrowest communication channel or the speed of the slowest processing node. Some applications depend mainly on latency, and some on bandwidth; so the two will perform differently, regardless of the choice of TCP or UDP. The TCP/UDP choice is almost completely orthogonal to the question of bandwidth or latency. The ONLY difference is that under TCP, transmission errors can cause future data to be buffered at the target node, and buffers have limited size... so in a path with very high latency and occasional errors, TCP can fail to meet the bandwidth potential of UDP over a similar path. Of course, the up-side is reliable messaging, which is not available with UDP. So... > Either you have a continuous > stream of data or you have intermittent packets. Yes. > Even if you were to > use TCP/IP for exchanging intermittent packets, it will behave from a > performance point of view like UDP. There is no such thing as performing "like UDP". It can perform like a continuous stream, or like intermittent packets with frequent round- trips... but neither is more or less UDP. As I said before, since many applications of UDP are for streaming large amounts of data with no round trips (e.g., video streaming, multicast broadcasting, ) and many applications of TCP are for intermitten communication with frequent round-trips (e.g., telnet, ssh, ftp control, most smtp and pop3 and imap, etc.), most people with experience in network protocols will think that you've got it quite backwards. You haven't really got it backward; there's really no significant relationship at all. > I thought I was stating something almost too obvious to mention, but > apparently it is not. I think your talk about TCP and UDP is confusing people. That's all. Latency and bandwidth is not at issue. Signaturewww.designacourse.com The Easiest Way To Train Anyone... Anywhere. Chris Smith - Lead Software Developer/Technical Trainer MindIQ Corporation I've re-read all the above and it seems to me that Roedy is arguing in a circle. If what you are interested in is stream performance, of course bandwidth is the dominant characteristic of interest. If you are interested in response times then of course latency is the dominant characteristic of interest. However, this is an *analytical* truth, not an insight about the Internet: it flows logically from the definitions of the units concerned. It has nothing specifically to do with TCP or UDP or IP; it is equally true of a garden hose. If you want to full a bucket quickly, choose a large bandwidth pipe, i.e. a large cross-section. If you care about the time it takes a drop of water to traverse the hose, choose a low-latency i.e. short hose. As for the statement that the number of hops is what determines UDP performance, this is simply false. Total latency is the sum of the individual latencies, no getting away from it. Similarly total effective bandwidth is the minimum of the bandwidths of the individual segments, nothing you can do about it. >I'm still not convinced. You say you're not making any such statement, >yet you go on to make such a statement. I am surely the expert on what I meant to say. I won't argue about how many different ways there are to interpret or twist my words. I was not writing a legal contract. My best wording of what I mean to say is at http://mindprod.com/jgloss/tcpip.html#PERFORMANCE If that is still unclear, please suggest a better wording. SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. > >I'm still not convinced. You say you're not making any such statement, > >yet you go on to make such a statement. > > I am surely the expert on what I meant to say. I'm just trying to communicate. I tried to sum up your statement in a certain way... but then you disagreed, and then went on to (apparently) say exactly what I had summed up earlier. Clearly, one of us is not understanding the words of the other. > My best wording of what I mean to say is at > http://mindprod.com/jgloss/tcpip.html#PERFORMANCE Ah. We still disagree, then. I guess the essence of our disagreement can be summed up by changing your statement: "... TCP/IP is like a bucket brigade to put out a fire, where a Datagram is like a single person running with the bucket back and forth ... TCP/IP does not wait for a packet to be delivered before sending the next." with this expanded version: "... TCP/IP is like a bucket brigade to put out a fire, where a Datagram is exactly like a bucket brigade, except that we're only looking at one bucket at a time. The actions of all parties are identical; TCP just provides the terminology and administrative capability to think about the whole brigade as a single thing. Neither TCP nor datagrams (UDP) necessarily wait for a packet to be delivered before sending the next. However, if I were writing an application that needed to wait for acknowledgement from the other side, I would almost certainly be using TCP. Hence, on average, UDP (datagram) applications probably get better performance (in terms of bandwidth) than TCP applications... but because of the nature of the problems they solve, not because TCP is somehow inherently inferior. The median is probably about the same." Signaturewww.designacourse.com The Easiest Way To Train Anyone... Anywhere. Chris Smith - Lead Software Developer/Technical Trainer MindIQ Corporation Roedy Green <my_email_is_posted_on_my_website@munged.invalid> writes in his Glossary: > However, if I were writing an > application that needed to wait for acknowledgement from the other > side, I would almost certainly be using TCP. Hence, on average, > UDP (datagram) applications probably get better performance > (in terms of bandwidth) than TCP applications... Roedy, I don't follow the logic here at all. (a) The 'hence' does not follow from what precedes; (b) if you needed to wait for an acknowledgement you would probably not be taking advantage of windowing, so why would you 'almost certainly be using TCP'? > ... but because of the > nature of the problems they solve, not because TCP is somehow > inherently inferior. The median is probably about the same." I don't know who said TCP is 'inferior'; I still don't know who is comparing apples and oranges; I don't know what this 'median' could possibly be measured with; and I still don't know why you refuse to add up latencies over a path. Your oft-repeated statement that the number of hops in UDP is critical assumes that all hops have the same latency, which is untrue. On Wed, 04 Jan 2006 09:18:18 GMT, "E.J. Pitt" <esmond.not.pitt@not.bigpond.com> wrote, quoted or indirectly quoted someone who said : >> However, if I were writing an >> application that needed to wait for acknowledgement from the other [quoted text clipped - 6 lines] >acknowledgement you would probably not be taking advantage of windowing, >so why would you 'almost certainly be using TCP'? What are you quoting? I don't see that either at http://mindprod.com/jgloss/tcpip.html or http://mindprod.com/jgloss/udp.html SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. > Roedy Green <my_email_is_posted_on_my_website@munged.invalid> writes in > his Glossary: [quoted text clipped - 4 lines] > > UDP (datagram) applications probably get better performance > > (in terms of bandwidth) than TCP applications... No, he didn't. That was me, suggesting to Roedy how I would change the statement from his glossary, which I believe is incorrect. > Roedy, I don't follow the logic here at all. (a) The 'hence' does not > follow from what precedes; (b) if you needed to wait for an > acknowledgement you would probably not be taking advantage of windowing, > so why would you 'almost certainly be using TCP'? The logic is as follows: Applications with round-trips (i.e., they wait on a response from the remote host) get lower bandwidth than applications that do not do so. Since waiting for a response assumes that it matters whether the response comes, such applications also need a reliable transport protocol and almost certainly would be implemented with TCP. So applications that stream large amounts of data (and get better bandwidth) may be written in TCP or UDP. Applications that do frequent round trips, on the other hand, are written almost exclusively in TCP. On average, TCP will see lower bandwidth because it includes applications that do round-tripping. > > ... but because of the > > nature of the problems they solve, not because TCP is somehow > > inherently inferior. The median is probably about the same." > > I don't know who said TCP is 'inferior' It was pre-empting a conclusion that seemed likely from the kind of logic in the original article. > ; I still don't know who is comparing apples and oranges; It's my believe that Roedy is. > I don't know what this 'median' could possibly be measured with; It's a guess. Jeez, I'm not defending a dissertation here. Do you have any reason to believe it's a bad guess? > and I still don't know why you refuse to add > up latencies over a path. Your oft-repeated statement that the number of > hops in UDP is critical assumes that all hops have the same latency, > which is untrue. I don't think Roedy really does refuse to add latencies over a path. I've been reading this thread, and I've never seen him refuse. Roedy is also not defending a dissertation. So yeah, of course latency at each hop differs. Nevertheless, as a general trend, an IP packet sent over more hops is going to experience higher latency than an IP packet sent over fewer hops. That's a _perfectly_ reasonable statement, in absence of specific reason to believe that the longer path has significantly lower latency per hop. Signaturewww.designacourse.com The Easiest Way To Train Anyone... Anywhere. Chris Smith - Lead Software Developer/Technical Trainer MindIQ Corporation >>I don't know what this 'median' could possibly be measured with; > > Do you have > any reason to believe it's a bad guess? Yes. What on earth is it a guess *at*? Measured in what? What exactly is the median of X apples and Y oranges? > So yeah, of course latency > at each hop differs. Nevertheless, as a general trend, an IP packet > sent over more hops is going to experience higher latency than an IP > packet sent over fewer hops. That's a _perfectly_ reasonable statement, > in absence of specific reason to believe that the longer path has > significantly lower latency per hop. It's a matter of logic. It's a universal statement which therefore can be disproved by a single counter-example. The latency around my home LAN is around 1ms per hop. The latency via xDSL to my ISP is around 227ms. QED. > Yes. What on earth is it a guess *at*? Measured in what? What exactly is > the median of X apples and Y oranges? The median bandwidth achieved by TCP applications that are network- limited in performance is likely to be about the same as the median bandwidth achieved by UDP applications that are similarly network- limited in performance. The mean bandwidth for such TCP applications, on the other hand, is likely to be lower than the mean bandwidth for such UDP applications. > It's a matter of logic. It's a universal statement which therefore can > be disproved by a single counter-example. The latency around my home LAN > is around 1ms per hop. The latency via xDSL to my ISP is around 227ms. QED. People speak in generalizations. In fact, that's one of the fundamental higher-level thought processes. If either Roedy or I claimed to be giving a rigorous performance model, you might have a point. As it is, I don't care. No one's implementing an IP routing algorithm based on Roedy's "bucket brigade" analogy. It's just a way of explaining concepts. If it succeeds, it will be intuitively obvious that the speed of a hop matters. If it doesn't succeed, it failed anyway. Signaturewww.designacourse.com The Easiest Way To Train Anyone... Anywhere. Chris Smith - Lead Software Developer/Technical Trainer MindIQ Corporation > if I miss a frame of the video, >that's fine; and I don't want to delay the receipt of the later frames >until the server can retransmit that frame that was missed. Hence, >streaming live audio/video is a counterexample to pushing this into the >TCP/UDP division. In that case, you have a stream, a bucket brigade of packets, so your performance behaves for all practical purposes much as if you had used TCP/IP for the stream. SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. On Wed, 28 Dec 2005 08:20:04 GMT, "E.J. Pitt" <esmond.not.pitt@not.bigpond.com> wrote, quoted or indirectly quoted someone who said : >(a) Subpackets have nothing to do with it. A fragemented UDP datagram >will never be reassembled. You and Gordon disagree on this. Where is the definitive documentation? SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. > On Wed, 28 Dec 2005 08:20:04 GMT, "E.J. Pitt" > <esmond.not.pitt@not.bigpond.com> wrote, quoted or indirectly quoted [quoted text clipped - 5 lines] > You and Gordon disagree on this. Where is the definitive > documentation? The definitive source is RFC 791. My reading is that fragmentation and reassembly happen at the IP layer, below UDP, and therefore fragmented UDP packets will always be reassembled. Some features present in the UDP protocol (RFC 768), such as checksums, wouldn't work without reassembly, suggesting this is a correct interpretation. What UDP/IP stacks do in real life may be another story, so the real definitive answer might come from sending some test packets across a network and seeing what comes out the other side. Or from a network guru, if any are handy. :) ----Scott. >>On Wed, 28 Dec 2005 08:20:04 GMT, "E.J. Pitt" >><esmond.not.pitt@not.bigpond.com> wrote, quoted or indirectly quoted [quoted text clipped - 16 lines] > network and seeing what comes out the other side. Or from a network > guru, if any are handy. :) Well I thought I was one ;-) but Gordon is correct. Reassembly takes place at the IP layer as the RFC and Stevens vol I & II make clear. So UDP datagrams can be reassembled. What *won't* happen is retransmission of a component part if it is lost, unlike TCP. Chris > On the other hand if you send a datagram and send a datagram in > return, the response time depends on the number of hops. This is the original statement I took issue with. Has it been corrected or retracted? > So even though the Internet is designed at the fundamental level > around delivery of individual packets, it is most efficient when > delivering streams. and the same is true of a garden hose. Or a piece of straight wire. basta cosi EJP > Chris (I don't know what you did to munge the References header, but it's lucky I saw your response. You might want to be more careful about that.) > > On the other hand if you send a datagram and send a datagram in > > return, the response time depends on the number of hops. > > This is the original statement I took issue with. Has it been corrected > or retracted? The statement above, as written, is true. I don't know who said it -- probably Roedy? -- so I couldn't retract it. But in any case, I don't see why anyone would retract it. The response time absolutely does depend on the number of hops (among other things, of course). My argument with Roedy is that the word "datagram" above is worse than irrelevant. The statement is technically true of all IP packets, assuming that you send one and then one gets sent back in response. However, this usage pattern is basically broken with UDP except in tightly controlled known reliable environments, since the packet is never guaranteed to arrive. Therefore, it's practically guaranteed you'd be using TCP when you observe this poor performance due to high latency and frequent round-trips, even though it's possible for any variety of IP. > and the same is true of a garden hose. Or a piece of straight wire. So? Several people have said they find Roedy's analogy useful. You think they are wrong for understanding it better in Roedy's terms? Frankly, it doesn't matter how wrong you think that is. It's still true. Signaturewww.designacourse.com The Easiest Way To Train Anyone... Anywhere. Chris Smith - Lead Software Developer/Technical Trainer MindIQ Corporation On Fri, 06 Jan 2006 09:07:11 GMT, "E.J. Pitt" <esmond.not.pitt@not.bigpond.com> wrote, quoted or indirectly quoted someone who said : >> On the other hand if you send a datagram and send a datagram in >> return, the response time depends on the number of hops. > >This is the original statement I took issue with. Has it been corrected >or retracted? It is true. It is also true it depends on the combined latencies of all the hops. SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. I am also thinking about the ease and "beauty" of a TCP server written in java. Just create a ServerSocket, go into an accept() loop and start worker threads for the connections you get. FINITO ! No need for Apache, Tomcat, Servlets or J2EE monsters like WebSphere. The only thing you might need is the ability to write a scanner&parser for the grammar of your client/server conversation. People who are not able to write a recursive descend parser might go with the J2EE monsters, the rest can implement the TCP acceptor described above. There might be a third possibility for those who don't know what LL(1) means: Serialization. No need for RMI of course - the simple Acceptor does the job. > I am also thinking about the ease and "beauty" of a TCP server written > in java. Just create a ServerSocket, go into an accept() loop and start [quoted text clipped - 4 lines] > able to write a recursive descend parser might go with the J2EE > monsters, the rest can implement the TCP acceptor described above. WebSphere, of course, does a lot of things... and implementing network protocols is the least of them. Don't get me wrong; certainly most of what WebSphere does is completely useless to most applications... but nevertheless there are additional features. One of those things, among the more useful, is to implement a considerably more scalable threading model than what you describe above. At least use java.util.concurrent.ThreadPoolExecutor. Even with plain network protocols, you can only design your own if you plan to implement both sides of the conversation, which is quite rare. If I want to talk to a web browser, I'm going to write servlets rather than re-implement HTTP 1.1. After all, servlets and Tomcat are pretty simple and lightweight wrappers around HTTP anyway, along with some decent higher-level capabilities. Signaturewww.designacourse.com The Easiest Way To Train Anyone... Anywhere. Chris Smith - Lead Software Developer/Technical Trainer MindIQ Corporation That was exaclty my point - who needs all the bells and whistles of WebSphere ?? The management guys who dictate its use ? What they need is an alternative to PowerPoint :-)) 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
|
©2009 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.