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

This is a discussion on tcp/ip twice on the same adapter - TCP-IP ; this is on my winxp box, with a asus mb with built in ethernet 3com gigabit lom 3c940 the ethernet has been cutting out so i reinstalled the vanilla 3com drivers which actually provision the adapter for dhcp and there ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 29

Thread: tcp/ip twice on the same adapter

  1. tcp/ip twice on the same adapter

    this is on my winxp box, with a asus mb with built in ethernet 3com gigabit
    lom 3c940
    the ethernet has been cutting out so i reinstalled the vanilla 3com drivers
    which actually provision
    the adapter for dhcp and there are 2 instances of tcp/ip installed
    1. the usual ms 'internet protocol(tcp/ip), as i said already configed for
    dhcp with the standard settings
    for dns, wins, etc
    2. this is new to me, something called 'Microsoft TCP/IP version 6', there
    are no properities available
    to provision just install and uninstall
    this is normal for xp?
    they work together somehow? or perform different functions?
    theres' plenty of info on each alone but nothing i've seen so far about both
    running on same adapter
    is it possible they can interfere with each other?
    bbxrider



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

    On Jun 25, 4:15 pm, "bbxrider" wrote:
    > this is on my winxp box, with a asus mb with built in ethernet 3com gigabit
    > lom 3c940
    > the ethernet has been cutting out so i reinstalled the vanilla 3com drivers
    > which actually provision
    > the adapter for dhcp and there are 2 instances of tcp/ip installed
    > 1. the usual ms 'internet protocol(tcp/ip), as i said already configed for
    > dhcp with the standard settings
    > for dns, wins, etc
    > 2. this is new to me, something called 'Microsoft TCP/IP version 6', there
    > are no properities available
    > to provision just install and uninstall
    > this is normal for xp?
    > they work together somehow? or perform different functions?
    > theres' plenty of info on each alone but nothing i've seen so far about both
    > running on same adapter
    > is it possible they can interfere with each other?



    IP6 is the eventual replacement for the (much) more common IP4. Most
    OS's now support both, but most users should simply ignore the IP6
    stack. For workstations, in most cases, if the IP6 stack is important
    on the network you're connected to, the IP6 equivalent of DHCP (Auto
    Config) will automatically set up the IP6 stack just as DHCP sets up
    the IP4 stack.


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

    On Jun 25, 4:24 pm, "robertwess...@yahoo.com"
    wrote:
    > IP6 is the eventual replacement for the (much) more common IP4. Most
    > OS's now support both, but most users should simply ignore the IP6
    > stack. For workstations, in most cases, if the IP6 stack is important
    > on the network you're connected to, the IP6 equivalent of DHCP (Auto
    > Config) will automatically set up the IP6 stack just as DHCP sets up
    > the IP4 stack.


    Hi Robert,

    I know you mean that "IPv6 is intended to be the eventual replacement
    of IPv4", but do you personally believe that? Fifteen years ago,
    there was a group of people who said that IPv6 would not reach the
    critical success its proponents claimed. The optimistic date of
    deployment of IPv6 was somewhere around 1996. Some proponents were
    ready to swear on their children that 2000 would be the drop-dead
    date.

    It is 2007, and while it is safe to say IPv6 is "deployed", the
    enthusiasm is not as much as one would expect.

    Also, IPv6 is suffering heavily from "My Baby Is Not Ugly" syndrome,
    which has, IMO, clouded the objectivity of is chief sponsors.

    Nevertheless, the U.S. government believes that we could have done a
    lot better, and they are willing to put their money behind their
    belief, specifically, by allocating funds to a new project, http://www.geni.net,
    whose purpose is none less than to redo TCP/IP completely from
    scratch. This is a bittersweet victory. Sweet because it indicates
    what many of us have known and been stating all along: that IPv6 is
    somewhat of a manged dog. Bitter because more than $1 billion has
    already been spent unnecessarily on this dog by people who insist that
    duct-tape is a prudent way to re-engineer extremely important systems.

    -Le Chaud Lapin-


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

    On Jun 26, 9:19 am, Le Chaud Lapin wrote:
    > I know you mean that "IPv6 is intended to be the eventual replacement
    > of IPv4", but do you personally believe that? Fifteen years ago,
    > there was a group of people who said that IPv6 would not reach the
    > critical success its proponents claimed. The optimistic date of
    > deployment of IPv6 was somewhere around 1996. Some proponents were
    > ready to swear on their children that 2000 would be the drop-dead
    > date.
    >
    > It is 2007, and while it is safe to say IPv6 is "deployed", the
    > enthusiasm is not as much as one would expect.
    >
    > Also, IPv6 is suffering heavily from "My Baby Is Not Ugly" syndrome,
    > which has, IMO, clouded the objectivity of is chief sponsors.
    >
    > Nevertheless, the U.S. government believes that we could have done a
    > lot better, and they are willing to put their money behind their
    > belief, specifically, by allocating funds to a new project,http://www.geni.net,
    > whose purpose is none less than to redo TCP/IP completely from
    > scratch. This is a bittersweet victory. Sweet because it indicates
    > what many of us have known and been stating all along: that IPv6 is
    > somewhat of a manged dog. Bitter because more than $1 billion has
    > already been spent unnecessarily on this dog by people who insist that
    > duct-tape is a prudent way to re-engineer extremely important systems.



    Honestly, I have no idea. Clearly the heavy NATing of the world has
    significantly relieved the primary pressure on IP4, but given the
    rather uneven distribution of IP addresses, there are still some hot
    spots with address shortages, namely the mobile phone world and China
    (and Asia in general). If Africa ever digs out of its economic hole,
    they'll be unpleasantly short too.

    The actual deployment of IP6 has clearly been far slower than anyone
    expected, yet it seems to be gathering some steam lately. For
    example, all versions of Windows now install and enable the IP6 stack
    by default, and if a home user's ISP choose to use IP6, they could
    (assuming a current version of Windows), and the end user would
    probably never notice. And there's now a solid IP6 stack on pretty
    much every (non-embedded) platform in the world (of course I'm
    supporting one of the few exceptions).

    I've been seeing customers requesting IP6 support too, although it's
    not clear how much this is a checklist item vs. actual usage, and we
    started adding IP6 support last year (not that there were more than
    minor changes, the biggest changes are almost always to code that
    handles the textual forms of IP addresses). And while my sample size
    is pretty small, our Asian customer base seems to be asking at a
    disproportionately high rate.

    I expect that IP4 will be around for years, no matter what, but we may
    get to a point where a significant majority of the Internet is IP6,
    and that may force the IP4 laggards, like the US, to actually start
    moving.


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

    On Jun 26, 9:58 am, "robertwess...@yahoo.com"
    wrote:
    > On Jun 26, 9:19 am, Le Chaud Lapin wrote:
    > > I know you mean that "IPv6 is intended to be the eventual replacement
    > > of IPv4", but do you personally believe that? Fifteen years ago,
    > > there was a group of people who said that IPv6 would not reach the
    > > critical success its proponents claimed. The optimistic date of
    > > deployment of IPv6 was somewhere around 1996. Some proponents were
    > > ready to swear on their children that 2000 would be the drop-dead
    > > date.

    > I expect that IP4 will be around for years, no matter what, but we may
    > get to a point where a significant majority of the Internet is IP6,
    > and that may force the IP4 laggards, like the US, to actually start
    > moving.


    What do you think about a challenger to IPv6, a completely new
    protocol that promises the same benefits as IPv6, but takes a
    different in its approach (better coherency, better API for
    programmers, etc.) ?

    I have thought about this for a while, and given all the "clean slate"
    activity that is going on in academia and elsewhere, it seems more
    reality than possibility that IPv6 will have competition in coming
    years.

    -Le Chaud Lapin-


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

    On Jun 26, 10:27 am, Le Chaud Lapin wrote:
    > What do you think about a challenger to IPv6, a completely new
    > protocol that promises the same benefits as IPv6, but takes a
    > different in its approach (better coherency, better API for
    > programmers, etc.) ?
    >
    > I have thought about this for a while, and given all the "clean slate"
    > activity that is going on in academia and elsewhere, it seems more
    > reality than possibility that IPv6 will have competition in coming
    > years.



    While there's always something to be said about a clean slate, I have
    trouble seeing it happen, except, perhaps, over a very long time. IP6
    was a fairly straightforward implementation effort for most stack
    vendors, and that still took a decade before most *new* machines were
    IP6 capable (and the vast majority of the installed base is still
    *not*).

    And there's already a great deal of IP6 traffic in the world (perhaps
    not by IP4 standards, but certainly by any other). Lots of cell
    phones, and cable operators have already jumped, and their usage is
    growing fast. I've seem wildly inconsistent stats, but certainly the
    number of non-traditional computing devices with IP addresses will be
    exceeding that of traditional computers in the near future, if it
    hasn't already. And a noteworthy percentage of those are already IP6,
    and the vendors responsible seem to be headed in that direction in
    general, so we may end up a few years down the road with more IP6
    nodes in the world than IP4 nodes, just not many in computers.

    So anything new has is going to have to offer very substantial
    advantages over IP6 to get all the embedded folks to switch (again),
    the ISPs to implement another protocol (when they've been dog slow
    getting IP6 deployed), and end users to start upgrading software to
    support it. No, I really don't see any significant deployment of any
    new protocol other than IP6 in the next ten years. And that only if
    it's less than five or six years before the new protocol is defined
    and working, and a general consensus forms that it will be implemented
    globally.

    FWIW, APIs are the least of the issue, and aren't really part of the
    protocol at all. And while Berkley Sockets has its problems, it has
    the huge advantage of familiarity and portability.


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

    On Jun 26, 1:07 pm, "bbxrider" wrote:
    > thanks for the interesting discussions here on ipv4 vs ipv6
    > robert, when you say " if the IP6 stack is important
    > on the network you're connected to, the IP6 equivalent of DHCP (Auto
    > Config) will automatically set up the IP6 stack just as DHCP sets up
    > the IP4 stack", does that mean IP4 and IP6 packets can coexist on the same
    > network, each handled by their respective stacks? and the ethernet will be
    > answering to 2 different addresses.?
    > sorry about the newbie question here, if there some info you can recomend
    > to answer these things, just pass it on, thanks
    > bbxrider



    Please don't top-post.

    Yes, multiple protocols can coexist on the same network, and on the
    same network adapter (NIC) - software permitting, of course. It's not
    so much that the ethernet card is responding to multiple addresses*,
    since the ethernet card has no idea that such a thing as an IP address
    even exists. Rather, there's a type field in the ethernet frame which
    identifies the protocol, and tells the hardware driver which protocol
    stack to pass the frame to. In all cases the ethernet card picks up
    frames with it's MAC address specified (plus broadcast frame,
    otherwise ignored here). Each protocol will have some way to
    determine what the MAC address of the target PC is. In IP4 this is
    ARP.

    So two protocols can coexist because they're completely separated by
    the "type" in the ethernet frame.

    Note that some protocols, like IP4, allow you to assign multiple IP
    addresses to the single NIC, and somehow the IP4 stack manages that,
    but that's all invisible from the ethernet level, which just sees MAC
    addresses.


    *Actually it's possible for a single NIC to handle multiple MACs, but
    that's an unnecessary complication here.


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

    On Jun 26, 12:46 pm, "robertwess...@yahoo.com"
    wrote:
    > On Jun 26, 10:27 am, Le Chaud Lapin wrote:
    > So anything new has is going to have to offer very substantial
    > advantages over IP6 to get all the embedded folks to switch (again),
    > the ISPs to implement another protocol (when they've been dog slow
    > getting IP6 deployed), and end users to start upgrading software to
    > support it. No, I really don't see any significant deployment of any
    > new protocol other than IP6 in the next ten years. And that only if
    > it's less than five or six years before the new protocol is defined
    > and working, and a general consensus forms that it will be implemented
    > globally.
    >
    > FWIW, APIs are the least of the issue, and aren't really part of the
    > protocol at all. And while Berkley Sockets has its problems, it has
    > the huge advantage of familiarity and portability.


    Well, so everyone knows, with the announcement of GENI, I have every
    intention of assembling a crackpot team to take a stab at a new,
    comprehensive protocol. I do not think IPv6 was straightforward at
    all, not to understand, and not to implement. I think that there was
    too much concern for backward-compatibility, and this prematurely
    strangled potentially good ideas.

    I also think that...ahem...that the 20-year-old programmers of today
    are not the same as 20-year-old programmers of the early 1970's. The
    intelligence factor stays the same...but the programmer's intuition
    and expectation changes drastically. I like the analogy between a
    Sopwith Camel engineer/pilot and an egnineer/F22-Raptor (http://
    en.wikipedia.org/wiki/F-22_Raptor) pilot. Both might be good
    pilots. Both might understand the principles of aerodynamics. But
    the F22-Raptor pilot will, by virtue of the point in time in which he
    is born, have very different expectations of how to design a fighter
    plane. Now if the Sopwith maintains intimate intuition with state of
    the art technology for the duration of his career, he might be able to
    keep up. But if he disengages, even briefly for a few years, some of
    the intuition is lost, and a lot of the technique is lost. After 20
    or 30 years, the fundamentals remains, but the aging pilot become less
    and less likely to solve unsolved problems. This is why a lot of
    revolutionary ideas tend to come from younger people - they do stand
    on the shoulders of giants, and have a huge foundation of knowledge
    based on the insight, dedication, and tenacity of those before them.

    The also have incredible tool sets. An older engineer relies on
    intuition, fundamentals, and made a slide-rule. A younger engineer
    gains intuition much quicker (by riding in his parent's plane for
    example), gains a bit of the fundamentals (but not as much as older
    engineer), and the tool-set is just incredible.

    So getting back to protocol design, the rate of iteration in 1980
    cannot be compared to the rate of iteration of today. Back then, the
    C language was not completely formed. C++ did not exist. Assembly
    language still had a serious advantage over other languages in many
    respects. A person actually had to wait in line with a set of punch
    cards. Today, a 15-year-old can download a world-class compiler with
    IDE, 10 of them in fact, with essentially every library routine
    imaginable for free. The design-build-test cycle is simply
    incomparable. Knowledge is for the taking, online. The only real
    limits are time and imagination, something that younger people just
    happen to have more of.

    Finally, I do not think it is necessary to even moderately supplant
    IPv4 (or IPv6) for a new protocol to take hold. I think this was a
    mistake of the IPv4 people, to assume as such. I think a new protocol
    can coexist quite nicely with IPv4, provided there are killer
    applications that can serve as motivation for the new protocol,
    applications that are impossible, or extremely difficult to run on
    IPv6.

    I also think that the API is inseparable to a certain extent from the
    protocol. The API is necessarily a relic of the chosen model. The
    idea of "protocol families", IMO, was always rediculous. Good design
    abhors incoherency, and that protocol families are a disguise for
    ignorance, uncertainty, and incoherency.

    In any case, with tunneling, there could be a new protocol running
    right now that few people know about. If that were the case, then the
    rest would be determine by how interested other people wanted it.

    -Le Chaud Lapin-


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

    On Jun 26, 11:48 am, v...@calcite.rhyolite.com (Vernon Schryver)
    wrote:
    > In article <1182871640.424294.286...@g4g2000hsf.googlegroups.c om>,
    > Le Chaud Lapin wrote:
    >
    > >> > critical success its proponents claimed. The optimistic date of
    > >> > deployment of IPv6 was somewhere around 1996.

    >
    > That conflicts with my recollections and dates on the IPng and
    > earliest IPv6 RFCs.
    >
    > >> > Some proponents were
    > >> > ready to swear on their children that 2000 would be the drop-dead
    > >> > date.

    >
    > My recollections of IETF mailing list discussions from about 1998 are
    > that 2003 was to be when IPv6 would be more popular than IPv4.


    I was thinking of the discussion that were going on with Big-Internet
    mailing list. The drop-dead date conveniently changed to a later drop-
    dead date as each drop-dead date came and went.

    > The NANAOG mailing list has more reasonable discussion of the issue
    > than nonsense about APIs and "coherency." Seehttp://www.google.com/search?q=site%3Amerit.edu+ipv6+nanog


    Thanks for the link.

    > Then there are those who are not crazy inventors but advocates of
    > such as 200 mpg carburators. They admit not understanding all of
    > the technical issues, but are confident that in academic labs and
    > elsewhere, people are working on clean slate approaches that will
    > produce pills to convert water to gasoline.


    History has shown that there is always a third group. Pick any
    technology that has been superseded by something better, and
    invariable, you will find that, while the Old Guards and the
    Organization of Crazies are scrambling to reinvent, someone else is
    quietly doing so. It is unfortunate that the kooks create skepticism,
    but this does not mean that the latter group does not exist.

    Even with ideas that are not even revolutionary from a technological
    point of view, but simple good from a commercial point of view, have
    been wildly successful. There are venture capitalists all over the
    world kicking themselves for letting such ideas get away.

    All three camps exists. I think it is a matter of time before a
    breakthrough happens.

    -Le Chaud Lapin-


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

    Jack Crisp Taco wrote:
    > In article <1182867583.040084.112560@u2g2000hsc.googlegroups.c om>,
    >> Also, IPv6 is suffering heavily from "My Baby Is Not Ugly" syndrome,
    >> which has, IMO, clouded the objectivity of is chief sponsors.

    >
    > I don't know why you are calling IPv6 "ugly". Please back it up or
    > back it down


    Maybe he means the fact that IPv6 still supports fragmentation? ;-)

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

    In article <1182886319.000277.122940@g4g2000hsf.googlegroups.c om>,
    jaibuduvin@gmail.com says...
    > Well, so everyone knows, with the announcement of GENI, I have every
    > intention of assembling a crackpot team to take a stab at a new,
    > comprehensive protocol. I do not think IPv6 was straightforward at
    > all, not to understand, and not to implement. I think that there was
    > too much concern for backward-compatibility, and this prematurely
    > strangled potentially good ideas.


    I assume you will be the lead "crackpot"

    When do you expect your protocol to be deployed? Given that IPv6, which
    is backwards compatible with IPv4, is taking so long to take over, I
    expect your protocol, which eschews backwards compatibility, to be
    popular by the year 3007. Maybe.

    > I also think that...ahem...that the 20-year-old programmers of today
    > are not the same as 20-year-old programmers of the early 1970's. The
    > intelligence factor stays the same...but the programmer's intuition
    > and expectation changes drastically. I like the analogy between a
    > Sopwith Camel engineer/pilot and an egnineer/F22-Raptor (http://
    > en.wikipedia.org/wiki/F-22_Raptor) pilot. Both might be good
    > pilots. Both might understand the principles of aerodynamics. But
    > the F22-Raptor pilot will, by virtue of the point in time in which he
    > is born, have very different expectations of how to design a fighter
    > plane.


    You've lost me with this analogy. I don't know anything about flying,
    but I'm pretty certain that pilots don't design fighter planes

    > Now if the Sopwith maintains intimate intuition with state of
    > the art technology for the duration of his career, he might be able to
    > keep up. But if he disengages, even briefly for a few years, some of
    > the intuition is lost, and a lot of the technique is lost. After 20
    > or 30 years, the fundamentals remains, but the aging pilot become less
    > and less likely to solve unsolved problems. This is why a lot of
    > revolutionary ideas tend to come from younger people - they do stand
    > on the shoulders of giants, and have a huge foundation of knowledge
    > based on the insight, dedication, and tenacity of those before them.


    Most 20-year-olds are greener than grass, have the least real-world
    experience, and haven't developed their intuition enough for it to be
    useful. They should still be in college. These people are at the
    beginning of their careers, not the height of it. They may be standing
    on the shoulders of the generations before them, but that just means
    their starting point is more contemporary. They still have a lot of
    growth and learning ahead of them.


    > So getting back to protocol design, the rate of iteration in 1980
    > cannot be compared to the rate of iteration of today. Back then, the
    > C language was not completely formed. C++ did not exist. Assembly
    > language still had a serious advantage over other languages in many
    > respects. A person actually had to wait in line with a set of punch
    > cards. Today, a 15-year-old can download a world-class compiler with
    > IDE, 10 of them in fact, with essentially every library routine
    > imaginable for free. The design-build-test cycle is simply
    > incomparable. Knowledge is for the taking, online. The only real
    > limits are time and imagination, something that younger people just
    > happen to have more of.


    Check your facts. Kernighan & Ritchie published their book on the C
    language in 1978, and the language existed as far back as 1972. C++
    wasn't invented until 1983, but it is close (within that time frame). I
    was using it in 1987. Punch cards? They were obsolete in the 1980s. I
    was programming as far back as 1982 (C, 8088 asm, BASIC to start with),
    and design-build-test cycle didn't involve punch cards.

    I don't know what country you live in, but here in America, the 15-to-20
    year olds are called "Gen-Y". Do you know what they're like? They are
    the generation of entitlement, always expecting to do less work and get
    paid more than their elders. Sit a 15-year-old in front a world-class
    compiler, and they might write "Hello world" and lose interest quickly
    when they realize programming is complex, rigorous _work_. They'd rather
    go play videogames. Oh, I'm sure somewhere out there is the next whiz
    kid, the next Bill Gates, but those are the exceptions, not the rule.


    > I think a new protocol
    > can coexist quite nicely with IPv4, provided there are killer
    > applications that can serve as motivation for the new protocol,
    > applications that are impossible, or extremely difficult to run on
    > IPv6.


    Such as?

    > I also think that the API is inseparable to a certain extent from the
    > protocol. The API is necessarily a relic of the chosen model. The
    > idea of "protocol families", IMO, was always rediculous. Good design
    > abhors incoherency, and that protocol families are a disguise for
    > ignorance, uncertainty, and incoherency.


    Really? How are protocol families "a disguise for ignorance,
    uncertainty, and incoherency"? The only incoherent, ignorant thing I see
    is your ranting

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

    On Jun 27, 8:50 pm, Ethan Howe wrote:
    > In article <1182886319.000277.122...@g4g2000hsf.googlegroups.c om>,


    First, I would like to thank you for an amusing response to my
    post.

    > I assume you will be the lead "crackpot"


    Yes, I will be the lead crackpot. Before long I shall be searching for
    crackpot-lites (smaller crackpots), who are willing to take a stab at
    doing something like this. Hey, people group together and build super-
    complex system that are not in their domain all the time. What better
    realm that software, to do something big like this. The material and
    distribution costs are essentially zero.

    > When do you expect your protocol to be deployed? Given that IPv6, which
    > is backwards compatible with IPv4, is taking so long to take over, I
    > expect your protocol, which eschews backwards compatibility, to be
    > popular by the year 3007. Maybe.


    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.

    > You've lost me with this analogy. I don't know anything about flying,
    > but I'm pretty certain that pilots don't design fighter planes


    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.

    > Most 20-year-olds are greener than grass, have the least real-world
    > experience, and haven't developed their intuition enough for it to be
    > useful. They should still be in college. These people are at the
    > beginning of their careers, not the height of it. They may be standing
    > on the shoulders of the generations before them, but that just means
    > their starting point is more contemporary. They still have a lot of
    > growth and learning ahead of them.


    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. If a
    60-year-old comes up with brilliant idea at 4:00 A.M. in morning, he
    knows...well, let's just say that they are more likely to stay put, if
    only to not wake the spouse. There is also that thing about free
    time, marriage, mortgage, children, real responsibilities...it should
    come as no surprise to you that people who exude brilliant insight in
    their careers often do it at a very early age.

    > Check your facts. Kernighan & Ritchie published their book on the C
    > language in 1978, and the language existed as far back as 1972. C++
    > wasn't invented until 1983, but it is close (within that time frame). I
    > was using it in 1987. Punch cards? They were obsolete in the 1980s. I
    > was programming as far back as 1982 (C, 8088 asm, BASIC to start with),
    > and design-build-test cycle didn't involve punch cards.


    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.

    > I don't know what country you live in, but here in America, the 15-to-20
    > year olds are called "Gen-Y". Do you know what they're like? They are
    > the generation of entitlement, always expecting to do less work and get
    > paid more than their elders. Sit a 15-year-old in front a world-class
    > compiler, and they might write "Hello world" and lose interest quickly
    > when they realize programming is complex, rigorous _work_. They'd rather
    > go play videogames. Oh, I'm sure somewhere out there is the next whiz
    > kid, the next Bill Gates, but those are the exceptions, not the rule.


    True. But that is the beauty of the way the world work. You don't
    need all 10,000 20-year-olds to do this kind of thing. You only need
    2 or 3 every now and then. The rest are called "consumers". I would
    not be surprised if there is some kid in say, Eastern Europe, who has
    promise in field of network design, and has to wait for his
    opportunity for artificial reasons.

    > > I think a new protocol
    > > can coexist quite nicely with IPv4, provided there are killer
    > > applications that can serve as motivation for the new protocol,
    > > applications that are impossible, or extremely difficult to run on
    > > IPv6.

    >
    > Such as?


    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.

    > Really? How are protocol families "a disguise for ignorance,
    > uncertainty, and incoherency"? The only incoherent, ignorant thing I see
    > is your ranting


    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.

    It is my opinion that true architects are not people who concoct
    "designs" so severely underspecified that their vagueness makes them
    utterly useless. True architects know. They will first make an
    overall design, but while they are making the design, the know in the
    back of their mind almost exactly which screw is going to be used by
    the "implementer". They know which grade of plastic will be used,
    which alloy, which programming language, which transistor, which type
    of lighting..

    A true architect is some who does not get specific, but could at a
    moments notice. In fact, it is the detailed insight that the good
    architect possess that makes him confident that his general design is
    appropriate.

    An analogy would be to design a rocket. Many people know that if you
    "shoot stuff out the exit hole at high velocity, you will get
    thrust." That's nice, and it's true, and someone could use Microsoft
    Visio to "design" a rocket based on this principle. I think you get
    the point. That is a far cry from someone who knows the details.

    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.

    If it so happens that, in this tedium, someone else besides the pseudo-
    architect comes up with something specific that is better than any
    specific existing design, or is the only specific design that derives
    from the vague "specification", the pseudo-architect can demand
    credit.

    I want to tackle the TCP/IP problem, while getting specific.

    Also, while we are on the subject, the OSI "protocol stack" is a great
    example of this vague specification non-sense. Everytime I read and
    OSI "specification", I want to vomit. Going through hundreds of pages
    of empty dribble that is like trying to eat air that smells good.

    -Le Chaud Lapin-


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

    vjs@calcite.rhyolite.com (Vernon Schryver) writes:

    > In article <1182871640.424294.286740@g4g2000hsf.googlegroups.c om>,
    > Le Chaud Lapin wrote:
    >
    >>> > critical success its proponents claimed. The optimistic date of
    >>> > deployment of IPv6 was somewhere around 1996.

    >
    > That conflicts with my recollections and dates on the IPng and
    > earliest IPv6 RFCs.


    There was an earlier version of IPv6, wasn't there? I, too, recall a
    mid-to-late 90's time frame for "the great IPv6 deployment", but then,
    between the explosion of the IPv4 internet and OSI, resources weren't
    really available to make it happen. That gave people time to think, I
    suppose, because the whole thing was rewritten right around there, and
    those RFCs are what we now know as IPv6.

    At least, that's the way I saw it. I only actively tracked IPv6 in the
    early 90's, but I recall being startled to discover in the later 90's
    that the current protocols were considerably different than the ones I
    saw five years earlier.

    Anyway, that might explain the difference in recollected dates: both
    are correct in their ways. Also, I think 1996 sounds about right for
    some of the first estimates for when IPv4 was going to crash and burn
    through address exhaustion, so there's also a possibility of confusing
    "IPv6 will be deployed by 1996 or else the sky will fall" with "IPv6
    will be ready to be deployed in 1996".

    -don

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

    In article <1183003672.280816.155020@g4g2000hsf.googlegroups.c om>,
    jaibuduvin@gmail.com says...

    > Hey, people group together and build super-
    > complex system that are not in their domain all the time.


    That sounds improbable. What's an example of someone building super-
    complex systems outside of their domain?

    > 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.


    Yes, intuition is gained through experience. So it sounds to me like you
    agree that a 20-year old has less intuition than a 60-year old.

    > 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.


    So you're switching your argument from "intuition" to "irrepressible
    energy and tenacity"? I can't dispute that 20-year-olds have more time
    and energy than 60-year-olds. I just don't believe that it makes up from
    a lack of experience at that age. I am not knocking younger people, just
    pointing out that experience (which builds intuition) counts.

    > 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 want to tackle the TCP/IP problem, while getting specific.


    What TCP/IP problem are you going to tackle?




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

    On Jul 7, 7:00 pm, Ethan Howe wrote:
    > In article <1183003672.280816.155...@g4g2000hsf.googlegroups.c om>,
    > That sounds improbable. What's an example of someone building super-
    > complex systems outside of their domain.


    First, by "outside of domain", I meant to say that the system built
    comes from someone who would not be considered a professional in that
    domain. One of my employees in 1998, Paul X, was a student when I
    hired him to help install a computer network for one of my clients.
    He learned that we were working on a short-range optical transceiver
    (free space), and offered to help. Within four months, he was well on
    his way to completing it, by himself, using no more than college-level
    knowledge of electrical engineering. He designed the circuit, the
    computer interface, and the enclosure. I believe he was 20 at the
    time, which would make him 29 now, so yes, the product was in his
    domain, but it was clear that he was very talented in what he did, and
    I know that there are many practicing (older) engineers who could not
    have shown as much talent.

    > Yes, intuition is gained through experience. So it sounds to me like you
    > agree that a 20-year old has less intuition than a 60-year old.


    Hmmm...no. Perhaps intuition is not the right word. There is
    something that 20-year-olds have that people seem to lose as they get
    older. Or perhaps it is that a 60-year-old has already made his walk,
    and the 20-year-old is not yet known. What I am saying is that I do
    not expect revolutionary behavior/thought-processes to come from 60
    year olds all of a sudden.

    > > 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.

    >
    > So you're switching your argument from "intuition" to "irrepressible
    > energy and tenacity"? I can't dispute that 20-year-olds have more time
    > and energy than 60-year-olds. I just don't believe that it makes up from
    > a lack of experience at that age. I am not knocking younger people, just
    > pointing out that experience (which builds intuition) counts.


    Yes, experience counts, but that will happen anyway. There is
    something else, beyond experience, that matters even more than
    experience, and if a 60-year-old has not exhibited whatever that thing
    is by the time he is 60, it is highly likely that he will not exhibit
    it thenceforth.

    > > 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?


    Changes to what K&R wrote. For example, when I read K&R for 1st time
    in 1988, I took strong typing for granted. Older C programmers had to
    tell me that it used to be the case that 'int' was once accepted by
    the compiler as an implicit type, which I thought was a bit strange.

    > What TCP/IP problem are you going to tackle?


    The usual:

    1. Naming
    2. Numbering
    3. Addressing
    4. Security
    5. Mobility
    6. Multicasting
    7. Better Interface Than Sockets
    8. etc.

    I want something that is 95% portable in C++. I am especially looking
    forward to getting rid of the sockets interface.

    -Le Chaud Lapin-




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

    In article <1183870033.612389.278790@g4g2000hsf.googlegroups.c om>,
    jaibuduvin@gmail.com says...
    > Yes, experience counts, but that will happen anyway. There is
    > something else, beyond experience, that matters even more than
    > experience, and if a 60-year-old has not exhibited whatever that thing
    > is by the time he is 60, it is highly likely that he will not exhibit
    > it thenceforth.


    Genius?

    > > What do you mean by not completely formed?

    >
    > Changes to what K&R wrote. For example, when I read K&R for 1st time
    > in 1988, I took strong typing for granted. Older C programmers had to
    > tell me that it used to be the case that 'int' was once accepted by
    > the compiler as an implicit type, which I thought was a bit strange.


    If that is what you mean by "not completely formed" then I must take
    issue. Don't confuse "changing" with "incomplete."

    There were only minor changes to C which took place between 1980 and
    1990. The example you gave is one of them. So int is not longer assumed
    by the compiler: does that make C completely formed? Was it incomplete
    before? No. The rules were changed, adjusted. It has nothing to do with
    completeness.

    And, how can you say you took strong typing for granted? The language is
    (still) weakly typed.


    > > What TCP/IP problem are you going to tackle?

    >
    > The usual:
    >
    > 1. Naming
    > 2. Numbering
    > 3. Addressing
    > 4. Security
    > 5. Mobility
    > 6. Multicasting
    > 7. Better Interface Than Sockets
    > 8. etc.


    This is very vague. I would be interested in seeing a statement of
    goals, offering specific promises as to what specific problems in each
    of these 8 areas your protocol will address.

    > I want something that is 95% portable in C++. I am especially looking
    > forward to getting rid of the sockets interface.


    You must mean C.

    C++ is not the lowest common denominator. C++ has no standard binary
    interface. Assuming that your sockets replacement is a DLL, do you plan
    to export mangled C++ names? If so, the exported symbols might not be
    usable from another compiler that uses a different name mangling scheme,
    let alone calling convention.

    And also, your C++ interface would not be directly usable by
    applications that use newer languages like C# and Java that are
    spreading like wildfire. Or languages like C, Pascal, Basic, Perl, etc.
    How would you address that in C++?

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

    Le Chaud Lapin writes:

    > 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.


    It's hard to take you seriously when you fail so completely to
    understand where protocol families came from what what they're good
    for. But then, you seem to view sockets as a solution to a protocol
    problem when it's actually a solution to an operating system problem,
    so it's really no surprised you're confused about a lot of the details.

    Did you really say you were going to be in charge of something?
    You sound like someone that tilts at windmills; perhaps you're
    talking about a project of that type.

    -don provan

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

    On Jul 8, 1:29 pm, Ethan Howe wrote:
    > In article <1183870033.612389.278...@g4g2000hsf.googlegroups.c om>,
    > jaibudu...@gmail.com says...
    > > > What TCP/IP problem are you going to tackle?

    >
    > > The usual:

    >
    > > 1. Naming
    > > 2. Numbering
    > > 3. Addressing
    > > 4. Security
    > > 5. Mobility
    > > 6. Multicasting
    > > 7. Better Interface Than Sockets
    > > 8. etc.

    >
    > This is very vague. I would be interested in seeing a statement of
    > goals, offering specific promises as to what specific problems in each
    > of these 8 areas your protocol will address.


    That would take probably 50 pages of writing.

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

    4. Is relatively easy. I want privacty, authenticity, and non-
    repudiation (in some cases) between any two nodes anywhere on the
    Internet, and the application programmer should not have to deal with
    the intricacies of security. It should be able to turn security on
    and off (against a socket perhaps) at will.

    5. Take the generalized case of mobility, the most extreme example you
    can think of, 500 nodes are all mobile, using wireless links that
    have 10-meter range, on a ship that is moving at 30 knots along a
    shore. Throw in security and multicasting. Demand that routing is
    always optimal or pseudo-optimal.

    6. Let PDA with camera multicast data stream to 1,000,000,000,000
    nodes on Internet, letting each node join and exit multicast session
    at will without saturating PDA. Model should pass the "20-year-old"
    test, where someone who is only 20 years old should be able to write
    the application that sends to those 1,000,000,000,000 nodes. In other
    words, if you do it in a "controlled environment" where the thing is
    so fragile that observers are not allowed to touch it, that does not
    count.

    7. This is easy and hard to describe at same time. Easy because
    sockets is old. Hard, because what I would offer exists in pieces all
    over the Internet. I do know that it should be trivial to establish
    secure links over Internet, not use SSL.

    > > I want something that is 95% portable in C++. I am especially looking
    > > forward to getting rid of the sockets interface.

    >
    > You must mean C.
    >
    > C++ is not the lowest common denominator. C++ has no standard binary
    > interface. Assuming that your sockets replacement is a DLL, do you plan
    > to export mangled C++ names? If so, the exported symbols might not be
    > usable from another compiler that uses a different name mangling scheme,
    > let alone calling convention.


    Well, neither does C, if you include sizes of scalars as part of the C
    interface.

    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.
    >
    > And also, your C++ interface would not be directly usable by
    > applications that use newer languages like C# and Java that are
    > spreading like wildfire. Or languages like C, Pascal, Basic, Perl, etc.
    > How would you address that in C++?


    I would let those languages fend for themselves. After all, that's
    what happens now anyway.i

    I would not demand that users use my C++ "Socket" class. It would be
    what I would put forth. Others will take what I provide and do
    whatever they feel necessary to get the protocol to work for their
    language.

    -Le Chaud Lapin-


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

    On Jul 8, 4:30 pm, don provan wrote:
    > Le Chaud Lapin writes:
    >
    > > 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.

    >
    > It's hard to take you seriously when you fail so completely to
    > understand where protocol families came from what what they're good
    > for. But then, you seem to view sockets as a solution to a protocol
    > problem when it's actually a solution to an operating system problem,
    > so it's really no surprised you're confused about a lot of the details.


    Layers layer layers.

    I was recently reading historical papers on the architecture of the
    Internet. It was interesting to see how, back in 1980, people were
    still musing about things that we take as law today.

    There are principles that have withstood test of time, like end-to-end
    principle, etc. and we, who work in this field, know what some of
    those principles are. 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.

    > Did you really say you were going to be in charge of something?
    > You sound like someone that tilts at windmills; perhaps you're
    > talking about a project of that type.


    Why would someone tilt at windmill?

    -Le Chaud Lapin-


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

    In article <1183943548.248117.275130@g4g2000hsf.googlegroups.c om>,
    jaibuduvin@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.

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

    > 4. Is relatively easy. I want privacty, authenticity, and non-
    > repudiation (in some cases) between any two nodes anywhere on the
    > Internet, and the application programmer should not have to deal with
    > the intricacies of security. It should be able to turn security on
    > and off (against a socket perhaps) at will.
    >
    > 5. Take the generalized case of mobility, the most extreme example you
    > can think of, 500 nodes are all mobile, using wireless links that
    > have 10-meter range, on a ship that is moving at 30 knots along a
    > shore. Throw in security and multicasting. Demand that routing is
    > always optimal or pseudo-optimal.
    >
    > 6. Let PDA with camera multicast data stream to 1,000,000,000,000
    > nodes on Internet, letting each node join and exit multicast session
    > at will without saturating PDA. Model should pass the "20-year-old"
    > test, where someone who is only 20 years old should be able to write
    > the application that sends to those 1,000,000,000,000 nodes. In other
    > words, if you do it in a "controlled environment" where the thing is
    > so fragile that observers are not allowed to touch it, that does not
    > count.
    >
    > 7. This is easy and hard to describe at same time. Easy because
    > sockets is old. Hard, because what I would offer exists in pieces all
    > over the Internet. I do know that it should be trivial to establish
    > secure links over Internet, not use SSL.


    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

    > > C++ is not the lowest common denominator. C++ has no standard binary
    > > interface. Assuming that your sockets replacement is a DLL, do you plan
    > > to export mangled C++ names? If so, the exported symbols might not be
    > > usable from another compiler that uses a different name mangling scheme,
    > > let alone calling convention.

    >
    > Well, neither does C, if you include sizes of scalars as part of the C
    > interface.


    On the contrary. Scalars in C are specific to the hardware platform
    (sizes, endianess, IEEE format), so any other language system running on
    the same platform has a mapping those those scalar types. It may be
    called something else in other languages, but the size is unchanged.

    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?

    > 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?

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

+ Reply to Thread
Page 1 of 2 1 2 LastLast