tcp/ip twice on the same adapter - TCP-IP

This is a discussion on tcp/ip twice on the same adapter - TCP-IP ; On Jul 8, 11:53 pm, Ethan Howe wrote: > In article , > jaibudu...@gmail.com says... > > > That would take probably 50 pages of writing. > > > 1, 2, & 3, cannot be really discussed in specific detail ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 29 of 29

Thread: tcp/ip twice on the same adapter

  1. Re: tcp/ip twice on the same adapter

    On Jul 8, 11:53 pm, Ethan Howe wrote:
    > In article <1183943548.248117.275...@g4g2000hsf.googlegroups.c om>,
    > jaibudu...@gmail.com says...
    >
    > > That would take probably 50 pages of writing.

    >
    > > 1, 2, & 3, cannot be really discussed in specific detail without
    > > simultaneously revealing solutions.

    >
    > You will pardon me if I take that statement with due skepticism. You
    > want to imply that you have a solution and that you're not revealing it,
    > but everything else you've said indicates that you are still at the
    > vague idea stage of your undertaking.


    I have some code.

    > Efforts like the development of IP and TCP were not done by one person
    > in their grandma's basement It involves many researchers.


    I honestly feel that is the problem with redoing these protocols - too
    many cooks in the kitchen. Ever tried to do something extremely
    complex while someone is talking to you? Not easy. That's about what
    happens when you get 500 bright people in a room and ask them to solve
    something like fixing TCP/IP. Now of course, there is off-time, where
    each researcher is left alone to think in isolation, but that
    isolation is not pure. From the beginning, the research is a
    collective effort, and trains of thought become constrained due to
    interdependent contracts of accommodation, backward compatibility
    being one. Others might be, "I'll do this, because Frank will not be
    happy if I don't, and it is a minor compromise anyway."
    Unfortunately, comprises (architectural defects) tend to influence
    each other combinatorially. There is probably some law about the
    survivability of meritocracy of a design in relation to the number of
    participants in the effort.

    > Do you have those 50 pages written? I assume you don't, so I have to
    > conclude then that you haven't figured out feature for feature exactly
    > what your protocol is going to achieve, just some vague ideas. Good luck
    > to you and your crackpot team. I'll check back in 3007 when you're ready
    > to deploy


    I do, in C++.

    > But back to my question, which you cleverly avoided answering. Are you
    > aware that C++ mangles names unless you use extern "C"? Are you aware
    > that you can export mangled names from a DLL, but then your DLL
    > interface would only be guaranteed compatible with the exact same C++
    > compiler version and vendor used to create the DLL?


    Yes, I see what you mean. You mean, how can I supplant sockets if I
    am to use C++ with no intermediate layer.

    > > I plan to do what is done now with TCP/IP. There will be a new packet
    > > format, and a new C++ interface for programming, like sockets.

    >
    > "Like sockets"? I thought you wrote "I am especially looking forward to
    > getting rid of the socket interface" and so are you saying that your new
    > C++ interface will be modeled after sockets?


    I do not plan to supplant sockets in the sense of getting rid of it
    entirely and immediately with my own API. In fact, I never believe in
    this idea. What I mean by "getting rid of" was to offer an
    alternative, meaning give programmers something else that they can use
    that is not sockets. At no point will I demand that sockets gets
    ripped out of the OS so that my API can take its place. I would
    expect side-by-side operation. So, by "getting rid of", I mean
    providing my new think with complete disregard for the old thing.
    What programmers do to reconcile the two...that would be their
    business, and as you know, there is always someone in the world who
    will find what they perceive to be a gap in functionality and create a
    bridge of sorts. But that would not be my domain. This mode of
    thought has become more prevalent in the last few years with all the
    "clean slate" TCP/IP redo projects coming up, but I have been
    preaching it for 20 years.

    > You do realize it sounds like you are reinventing the wheel, right?


    You can say delusional if that's what you mean.

    -Le Chaud Lapin-


  2. Re: tcp/ip twice on the same adapter

    Le Chaud Lapin writes:

    > Layers layer layers.


    Neither sockets nor protocol families have anything to do with
    layering.

    > But I do not see many people stepping back and
    > reflecting on the trend, on what is going on. I do not see many
    > people looking at the steady state model and asking, what is the
    > natural order of it.
    >
    > I think if people where to do that, they would discover that the model
    > does not stop at Layer 3 or 4, but continues upward. The notion of
    > bootstrap as a mechanism for scaffolding on the architectural
    > framework persists.


    I'm not clear where you were that you missed the OSI effort back in
    the 80's and 90's during which what goes on above layer 4 was explored
    in depth. In presentation layer, the result was ASN.1, although it's
    been replaced now almost entirely (from what I can see) with XML and
    its variants, such as HTML. But the lesson learned, I would claim, is
    that the consideration of things above layer 4, while logically
    valuable, do not tend to be universal: each application has its own
    requirements, and the requirements tend to be different enough that no
    one presentation mechanism (for example) can or should be expected to
    handle them all. This has led to the current state where the upper
    layers mechanisms are built into the application protocol, sometimes
    by using standards such as XML and UCS-8, sometimes with something
    else. What about this are you suggesting could be improved?

    > Why would someone tilt at windmill?


    It is typical of windmill tilters that they are unaware of the true
    nature of their activities.

    -don

  3. Re: tcp/ip twice on the same adapter

    Le Chaud Lapin writes:

    > What programmers do to reconcile the two...that would be their
    > business, and as you know, there is always someone in the world who
    > will find what they perceive to be a gap in functionality and create a
    > bridge of sorts. But that would not be my domain. This mode of
    > thought has become more prevalent in the last few years with all the
    > "clean slate" TCP/IP redo projects coming up, but I have been
    > preaching it for 20 years.


    What programmers did to reconcile TCP/IP with UNIX was, in fact,
    sockets. Could you explain, perhaps, what is different about your
    protocol that would make sockets not the correct solution to it, as
    well? Or, perhaps instead, could you explain where your plan of a new
    API stops and "what programmers do" takes up? You speak as if TCP/IP
    invented sockets, but the truth is quite different, so I'm having a
    hard time following your logic. Frankly, the more you talk, the more
    I'm getting is nothing but megalomania.

    -don

  4. Re: tcp/ip twice on the same adapter

    On Jul 9, 12:28 pm, don provan wrote:
    > Le Chaud Lapin writes:
    > What programmers did to reconcile TCP/IP with UNIX was, in fact,
    > sockets. Could you explain, perhaps, what is different about your
    > protocol that would make sockets not the correct solution to it, as
    > well? Or, perhaps instead, could you explain where your plan of a new
    > API stops and "what programmers do" takes up? You speak as if TCP/IP
    > invented sockets, but the truth is quite different, so I'm having a
    > hard time following your logic. Frankly, the more you talk, the more
    > I'm getting is nothing but megalomania.


    There is probably no Earth-shattering single feature of my socket
    implementation, just many small details that make the whole more
    usable.

    It is 95% portable, meaning that the code will run on any multi-
    threaded OS. This is strict portability, meaning that #define's are
    not allowed. It cannot not be known in advance what the nature of the
    OS is, only that it provides certain basic features, multi-threading
    being one of them. Once those inherently non-portable parts are
    ported, the remaining code should work.

    My socket is not a handle but full object (somewhat complex) object
    from the start. [Undoubtedly, as mentioned, some non-OO programmer
    will not be happy with this and write a wrapper that is more tractable
    in their own language.]

    Security is built-in. There is no need to go hunting for your own
    certificates. Just turn it on, turn it off.

    Mobility is built-in. There is very little that a programmer needs to
    do to track a moving node, even if it is 1,000 moving nodes.

    Multicasting is easy and much more automatic than today. Again, it
    must pass the bright-20-year-old test, to be considered easy under my
    rules.

    Blocking has been normalized. People who have written socket
    applications probably know what happens when you try to write Unix/
    Windows portable code with blocking built into the application, that
    involves GUI blocking plus socket I/O blocking plus File I/O blocking,
    maybe waiting on a queue...etc. The problem is that the
    synchronization framework is not portable, so each programmer must
    home-grow solutions. This has been normalized to a regular model, so
    that the programmer does not get that eerie feeling that the whole
    thing will lock up at any moment. And again, it's portable.

    Unnecessary copying from application space to MAC/Phy has almost been
    eliminated. Encoder/Decoders are defined in application space and do
    not require redundant data moves.

    It is the combination of man things like the above that make
    programming a lot easier.

    -Le Chaud Lapin-







  5. Re: tcp/ip twice on the same adapter

    On Jul 9, 12:19 pm, don provan wrote:
    > Le Chaud Lapin writes:
    > I'm not clear where you were that you missed the OSI effort back in
    > the 80's and 90's during which what goes on above layer 4 was explored
    > in depth. In presentation layer, the result was ASN.1, although it's
    > been replaced now almost entirely (from what I can see) with XML and
    > its variants, such as HTML. But the lesson learned, I would claim, is
    > that the consideration of things above layer 4, while logically
    > valuable, do not tend to be universal: each application has its own
    > requirements, and the requirements tend to be different enough that no
    > one presentation mechanism (for example) can or should be expected to
    > handle them all. This has led to the current state where the upper
    > layers mechanisms are built into the application protocol, sometimes
    > by using standards such as XML and UCS-8, sometimes with something
    > else. What about this are you suggesting could be improved?


    This is a good point, but I was thinking more along the lines of
    multicasting, etc...the fact that the routers have to participate if
    the solution is to scale. But that is not the problem. Every
    researcher in this space already knows that.

    The problem is that if I want to write a mutli-cast program right now,
    in the next 4 hours before I eat my dinner, I can be pretty certain
    that, by dinner time, the program will not be finished.

    The facility by which features are used are somewhat incoherent at
    this points. The structure of the entire system is somewhat
    incoherent in fact. So by layers, I mean one should not only
    acknowledge the feature set, but structure the system in such a way
    that the whole becomes regular. At that point, it should be much
    easier for me to write a multicasting application. Or a secure
    application (with connection to any arbitrary node). Or an
    application that tracks the peers with which it communicates.

    To do these things requires a reordering of concepts and components,
    some of which have been available since the 1960's. When that
    reordering occurs, it is my opinion that the structure of all that is
    in place will strongly suggest that one break Layer 3&4. Wire formats
    will only be the beginning. The most important change will be a
    restructuring in state, both in terms of what state is present in a
    socket, and how that state is managed.

    In other words, if you were to look at the packet formats of TCP/IP,
    that would tell only half the story. You have to look at how the
    software cycles state in TCP/IP buffers (retransmission). I am saying
    that, the same thing will need to be done for all the other problems,
    not just retransmission.

    I am learning that the structure to facilitate solutions to these
    problems is surprisingly "unflat", if the goal is optimum mental
    relief while using the system. But again, I am of the old school of C
    and simplicity, so by default, I generally resist things like XML as a
    wire format, programmable packets, etc. I think it is difficult to
    find a good balance.

    -Le Chaud Lapin-


  6. Re: tcp/ip twice on the same adapter

    In article <1183003672.280816.155020@g4g2000hsf.googlegroups.c om>,
    jaibuduvin@gmail.com says...
    > I was thinking more like 2015. The GENI people (www.geni.net) seem to
    > be looking at a 10-15 development cycle, and that is mostly for
    > research. I am hoping for implementation and deployment within 7
    > years.


    I may hold you to that. And when the date starts slipping, would you
    like me to point out that you said the same thing about IPv6 as "proof"
    that it was flawed?

    > I used fighter planes for emphasis, but I meant regular aircraft. My
    > point is that intuition held by a single individual can be extremely
    > powerful. But to gain that intuition, it helps to be in the trenches
    > where the action is.


    No, you were trying to make a point about the intuition of the 20-year-
    old programmer. And what I'm saying is that the 20-year-old programmer
    doesn't have enough experience to have a useful intuition, because
    they're not even out of school yet, let alone spent any time "in the
    trenches."

    > Yes, but they posses certain qualities that 60-year-olds tend to
    > lose. For instance, if a 20-year-old comes up with brilliant idea at
    > 4:00 A.M. in morning, (it does happen sometimes), he might jump out
    > of to explore further with irrepressible energy and tenacity.


    Energy and tenacity are not going to make up for a 20-year-old's
    unfocused attention span, lack of experience, and general disinterest in
    working hard to master anything. That generation expects the world for
    nothing. Generation Y isn't the generation that wakes up a 4am, they are
    the generation that's going to bed at 4am...after a long night of
    partying.

    > I did not say C was created in 1980. FYI, K&R is one of the few books
    > that I read letter-for-letter, front-to-back, every single word. I
    > said that it was not completely formed.


    What do you mean by "not completely formed"?

    > Well if I said what some of those killer applications were, someone
    > might try to implement them using TCP/IP, and though the result would
    > not be perfect, if there were any success at all, it would preempt my
    > right to retain intellectual property surround the idea.


    If there were any successes implementing your killer applications with
    existing protocols like IPv6, it would prove that your assertion, that
    these applications "are impossible, or extremely difficult to run on
    IPv6" (your words) is untrue, wouldn't it?

    Okay, I noticed that you changed your stance to "the result would not be
    perfect" but it doesn't need to be perfect to provide value. If you
    doubt that, check out this wonderful thing called The Internet that uses
    mostly IPv4. It isn't perfect, but it works. Tell me, what problem is
    your hypothetical new protocol going to fix?

    > Protocol families, IMO, fall in the same category as ultra-abstract
    > base classes in OO programming, like the infamous "Thing" object,
    > which is base class for everything because everything is a thing.


    Abstract is not the same thing as is "vague."

    > So...IMO, protocol families is one of the earliest examples of the we-
    > do-not-know-but-would-still-like-credit-nevertheless mindset. It is
    > when someone does not possess sufficient insight to get specific, to
    > know what needs to be, in order to write a usable specification, so
    > they take what they feel is the next best option, which is to write up
    > something so vague that it is essentially pertinent to anything that
    > might be devised later, and called it "flexible", when in fact it is
    > so vague that it is not only useless, but burdens the implementer with
    > a false sense of structure, a tedium that would not have existed if
    > something specific had been chosen in the first place.


    I don't know what you mean by "false sense of structure" or tedium. How
    much extra code is involved in specifying a protocol family? One or two
    lines of code? How is this tedium?

  7. Re: tcp/ip twice on the same adapter

    In article <1183982157.269174.264580@57g2000hsv.googlegroups.c om>,
    jaibuduvin@gmail.com says...
    > have some code.


    That's cool. Since I can real C/C++ code, I'd love to see it. Is it
    available on SourceForge?

    > I honestly feel that is the problem with redoing these protocols - too
    > many cooks in the kitchen. Ever tried to do something extremely
    > complex while someone is talking to you? Not easy. That's about what
    > happens when you get 500 bright people in a room and ask them to solve
    > something like fixing TCP/IP. Now of course, there is off-time, where
    > each researcher is left alone to think in isolation, but that
    > isolation is not pure. From the beginning, the research is a
    > collective effort, and trains of thought become constrained due to
    > interdependent contracts of accommodation, backward compatibility
    > being one. Others might be, "I'll do this, because Frank will not be
    > happy if I don't, and it is a minor compromise anyway."
    > Unfortunately, comprises (architectural defects) tend to influence
    > each other combinatorially. There is probably some law about the
    > survivability of meritocracy of a design in relation to the number of
    > participants in the effort.


    So you equate participation and input from others as either
    "distractions" or "compromising." That's not necessarily always the
    case. If you put together a team of like-minded, smart individuals, even
    if they don't agree on everything, they will each bring something to the
    table. As long as the group has their egos in check, it will be possible
    to create designs that are better than what any single individual would
    have thought up.

    So, to use your example, rather than treat the person talking to you
    while you are working as a distraction, stop what you are doing and
    listen. If they are focused on the same problem as you, maybe they have
    something useful, relevant, and important to say.

    The best thing you can do for your new protocol is peer review.


    > > Do you have those 50 pages written? I assume you don't, so I have to
    > > conclude then that you haven't figured out feature for feature exactly
    > > what your protocol is going to achieve, just some vague ideas. Good luck
    > > to you and your crackpot team. I'll check back in 3007 when you're ready
    > > to deploy

    >
    > I do, in C++.


    Great. Upload your code, in whatever state it's in, to SourceForge. (I
    assume you plan to open license or GPL license the code)


    > > But back to my question, which you cleverly avoided answering. Are you
    > > aware that C++ mangles names unless you use extern "C"? Are you aware
    > > that you can export mangled names from a DLL, but then your DLL
    > > interface would only be guaranteed compatible with the exact same C++
    > > compiler version and vendor used to create the DLL?

    >
    > Yes, I see what you mean. You mean, how can I supplant sockets if I
    > am to use C++ with no intermediate layer.


    No, my question is simpler then that. I mean, which best describes the
    form that your library's code will take at runtime?

    1. A DLL written in C++ that exports a C interface
    2. A static library written in C++ that exports a C++ interface
    3. A static library written in C++ that exports a C interface
    4. C++ source code only

    > What programmers do to reconcile the two...that would be their
    > business, and as you know, there is always someone in the world who
    > will find what they perceive to be a gap in functionality and create a
    > bridge of sorts. But that would not be my domain.


    Why would they do that? I don't believe that it will come to the point
    where reconciling the two will be necessary, because if they've chosen
    your non-TCP protocol to begin with, why do they care about TCP? Given
    the choice between an protocol that's theoretically better, but has zero
    footprint vs a protocol that's established and universal, but has some
    limitations, most programmers would use the universal one.

    > This mode of
    > thought has become more prevalent in the last few years with all the
    > "clean slate" TCP/IP redo projects coming up, but I have been
    > preaching it for 20 years.


    How many people have 20 years of preaching converted?

  8. Re: tcp/ip twice on the same adapter

    On Jul 10, 9:42 am, Ethan Howe wrote:
    > In article <1183982157.269174.264...@57g2000hsv.googlegroups.c om>,
    > jaibudu...@gmail.com says...
    >
    > > have some code.

    >
    > That's cool. Since I can real C/C++ code, I'd love to see it. Is it
    > available on SourceForge?


    No, it is still in development.

    > So you equate participation and input from others as either
    > "distractions" or "compromising." That's not necessarily always the
    > case. If you put together a team of like-minded, smart individuals, even
    > if they don't agree on everything, they will each bring something to the
    > table. As long as the group has their egos in check, it will be possible
    > to create designs that are better than what any single individual would
    > have thought up.


    Perhaps. That was supposed to be the model for IPv6, but IMO, that
    effort failed. I do believe in teamwork, especially in areas that
    require abilities and insight beyond architectural skill. The best
    two examples I can think of in terms of redoing a protocol stack are
    cryptography and stochastics, both of which are extremely necessary in
    doing a protocol stack.

    > So, to use your example, rather than treat the person talking to you
    > while you are working as a distraction, stop what you are doing and
    > listen. If they are focused on the same problem as you, maybe they have
    > something useful, relevant, and important to say.


    Yes, that is true. But in almost all cases, of people I have
    encountered in this area, their preconceive notions of how things
    should be are so different than what I am thinking that the whole
    exercise becomes me listening to them regurgitate what they read about
    TCP/IP.

    However, I will admit that there are a few people, some in the public
    eye, scattered across the Internet, who might share similar visions of
    pieces of my model. I have yet to see anyone try to take on the whole
    thing at once, even with a small group of say, 10 people.

    > The best thing you can do for your new protocol is peer review.


    LOL. Oh, my peers will get to review it all right.

    > > > Do you have those 50 pages written? >

    > > I do, in C++.

    >
    > Great. Upload your code, in whatever state it's in, to SourceForge. (I
    > assume you plan to open license or GPL license the code)


    Eventually sure, but premature presentation can be a killer.

    > > Yes, I see what you mean. You mean, how can I supplant sockets if I
    > > am to use C++ with no intermediate layer.

    >
    > No, my question is simpler then that. I mean, which best describes the
    > form that your library's code will take at runtime?
    >
    > 1. A DLL written in C++ that exports a C interface
    > 2. A static library written in C++ that exports a C++ interface
    > 3. A static library written in C++ that exports a C interface
    > 4. C++ source code only


    Right now, it is #2.

    > > What programmers do to reconcile the two...that would be their
    > > business, and as you know, there is always someone in the world who
    > > will find what they perceive to be a gap in functionality and create a
    > > bridge of sorts. But that would not be my domain.


    By reconcile, I meant your name-mangling issue. Since my library would
    be implemented as a static C++ library, there will be someone,
    somewhere on the Internet, who will recognize this deficiency and
    attempt to wrap it so that it the wrapped thing conforms to #1.

    > Why would they do that? I don't believe that it will come to the point
    > where reconciling the two will be necessary, because if they've chosen
    > your non-TCP protocol to begin with, why do they care about TCP? Given
    > the choice between an protocol that's theoretically better, but has zero
    > footprint vs a protocol that's established and universal, but has some
    > limitations, most programmers would use the universal one.


    No incumbent is untouchable, especially when two options exist side by
    side. One of the last things I would do is insist that everyone
    switch to my model. I would simply put it out there and let each
    individual decide. There will be features and benefits of the new
    model, and market forces that will lead to a decision. If it turns
    out that only hobbyist like it, so be it. That will be the truth,
    that there is nothing compelling enough to get someone to write a new
    application against the new protocol. I am hoping that there will be
    at least one user beyond hobbyists.

    > > This mode of
    > > thought has become more prevalent in the last few years with all the
    > > "clean slate" TCP/IP redo projects coming up, but I have been
    > > preaching it for 20 years.

    >
    > How many people have 20 years of preaching converted?


    Three.

    -Le Chaud Lapin-



  9. Re: tcp/ip twice on the same adapter

    On Jul 10, 9:11 am, Ethan Howe wrote:
    > In article <1183003672.280816.155...@g4g2000hsf.googlegroups.c om>,
    > jaibudu...@gmail.com says...
    > I may hold you to that. And when the date starts slipping, would you
    > like me to point out that you said the same thing about IPv6 as "proof"
    > that it was flawed?


    If the proponents of IPv6 had proclaimed that they would delay
    deployment because there were some things still not worked out, I
    would have been agreeable with that. Nothing wrong with delays,
    especially for something that is meant to be used by billions of
    people when it is fully-cooked.

    But that is not what happened. IPv6 is being offered today. It is
    somewhere on the computer I am using to type this, I think. Flaws
    manifest in structure, not time of delivery.

    > Energy and tenacity are not going to make up for a 20-year-old's
    > unfocused attention span, lack of experience, and general disinterest in
    > working hard to master anything. That generation expects the world for
    > nothing. Generation Y isn't the generation that wakes up a 4am, they are
    > the generation that's going to bed at 4am...after a long night of
    > partying.


    Well, of course I do not mean any/all 20-year-olds. My original point
    is that, if you take two people, both predestined to do protocol
    research, I would rather bet on the 20-year-old as the 60-year-old.
    The problem is finding a 20-year-old who is just as much committed to
    this field as the 60-year-old. Once that is done [not at easy task],
    then, even though the 20-year-old is still wet behind the ears, I
    think it is worth the gamble because his/her future would lie ahead,
    not behind. I think this is why many research institutions have Young
    Investigator or Young Inventor programs...perhaps they realize that
    there is a period of unnecessary waste that occurs during youth for
    promising young researchers, and they want to find a way to circumvent
    the process that leads to that waste, or at least accelerate the
    process that leads to the young researcher's matriculation to where s/
    he needs to be.

    > > I did not say C was created in 1980. FYI, K&R is one of the few books
    > > that I read letter-for-letter, front-to-back, every single word. I
    > > said that it was not completely formed.

    >
    > What do you mean by "not completely formed"?


    I mean that there were still significant pieces of language that were
    still in development. My first C++ book, for example, came out of the
    trash can [I had this thing about people throwing away books.] So I
    thought I would learn it. I took it out of the trash, installed a
    Microsoft compiler, and ran a few programs. I got to a keyword called
    "overload" or "overloaded", or something like that. The compiler
    said, "this keyword has been deprecated and no longer exists." The
    book was several years old.

    So I went out and bought an up-to-date C++ book. I later learned that
    template model had changed, placement new had not been invented...etc.

    This is what I mean about "not completely formed."

    > If there were any successes implementing your killer applications with
    > existing protocols like IPv6, it would prove that your assertion, that
    > these applications "are impossible, or extremely difficult to run on
    > IPv6" (your words) is untrue, wouldn't it?


    No. People have flown from the United States to Europe in aircraft
    that no reasonable individual board today. Those who survived and did
    not crash probably found it extremely difficult.

    There is a wide spectrum between extremely easy and extremely
    difficult. The arena will decide where in the spectrum a concoction
    lies.

    > Okay, I noticed that you changed your stance to "the result would not be
    > perfect" but it doesn't need to be perfect to provide value. If you
    > doubt that, check out this wonderful thing called The Internet that uses
    > mostly IPv4. It isn't perfect, but it works. Tell me, what problem is
    > your hypothetical new protocol going to fix?


    None. In fact, I have no protocol. I'm just hoping to get part of
    the $300 million that the other researchers are getting to provide
    their own fixes.

    Seriously, I already listed the problems in a previous response to
    you.

    This question could be asked about almost any technology that "needs
    to be fixed." One could say that there is nothing to be fixed at
    all. In fact, one could argue that IPv6 itself was not even
    necessary.

    What matters is how much better the new is over the old. So "fixed"
    should not be taking as one of two states. Fixed, by definition, is
    generally relative. Fixed compared to what? Fixed often times means
    easier. The question then becomes, "How much easier?"

    > > Protocol families, IMO, fall in the same category as ultra-abstract
    > > base classes in OO programming, like the infamous "Thing" object,
    > > which is base class for everything because everything is a thing.

    >
    > Abstract is not the same thing as is "vague."


    > I don't know what you mean by "false sense of structure" or tedium. How
    > much extra code is involved in specifying a protocol family? One or two
    > lines of code? How is this tedium?


    I am saying that the socket model attempted to be a catch-all for
    protocols. It is the principle that I am against, the presumption
    that value is being offered by this catch-all model. I see very
    little value in providing run-time choice of DECNET versus TCP/IP in a
    socket.

    -Le Chaud Lapin-



+ Reply to Thread
Page 2 of 2 FirstFirst 1 2