The documentation claims that multiple stacks can be loaded by io-net. Can
anyone provide examples?
Thanks,
Issam
I don’t know about multiple TCP/IP stack but multiple stack that for sure.
Qnet and TCP/IP have been running for quite some time, both are protocol
stack.
“Issam Haddad” <ihaddad@asurent.com> wrote in message
news:9kmh3r$j4p$1@inn.qnx.com…
The documentation claims that multiple stacks can be loaded by io-net.
Can
anyone provide examples?Thanks,
Issam
Issam Haddad a écrit :
The documentation claims that multiple stacks can be loaded by io-net. Can
anyone provide examples?Thanks,
Issam
Strange, multiple tcp/ip stacks would mean multiple hostnames for the same
machine. If no, I’m interested!
Alain.
Exactement! VLAN…
“Alain Bonnefoy” <alain.bonnefoy@icbt.com> wrote in message
news:3B700019.5AB32C95@icbt.com…
Issam Haddad a écrit :
The documentation claims that multiple stacks can be loaded by io-net.
Can
anyone provide examples?Thanks,
Issam
Strange, multiple tcp/ip stacks would mean multiple hostnames for the same
machine. If no, I’m interested!Alain.
You can achive multiple host names in several ways.
-
Multiple interfaces will give multiple IP addresses, each would have its
own hostname. -
You can also use alias to get multiple hostnames.
What do you want to acomplish with multiple host names?
Bill Caroselli
“Alain Bonnefoy” <alain.bonnefoy@icbt.com> wrote in message
news:3B700019.5AB32C95@icbt.com…
Issam Haddad a écrit :
The documentation claims that multiple stacks can be loaded by io-net.
Can
anyone provide examples?Thanks,
Issam
Strange, multiple tcp/ip stacks would mean multiple hostnames for the same
machine. If no, I’m interested!Alain.
“Bill Caroselli (Q-TPS)” a écrit :
You can achive multiple host names in several ways.
Multiple interfaces will give multiple IP addresses, each would have its
own hostname.You can also use alias to get multiple hostnames.
What do you want to acomplish with multiple host names?
Bill Caroselli
“Alain Bonnefoy” <> alain.bonnefoy@icbt.com> > wrote in message
news:> 3B700019.5AB32C95@icbt.com> …
Issam Haddad a écrit :The documentation claims that multiple stacks can be loaded by io-net.
Can
anyone provide examples?Thanks,
Issam
Strange, multiple tcp/ip stacks would mean multiple hostnames for the same
machine. If no, I’m interested!Alain.
I though about that because we are going to use intensively our qrtp server but,
as I don’t know now if I will be able to connect it on the 100 MB network
because we are normally connected to it via 10/100 MB switches, I though to use
2 or more network cards to connect our developpers on the different IP adresses
of the server.
just to have an idea, what’s the difference between one 100 MB network access
and ten 10 MB network access with several client access at the same time?
Thanks,
Alain.
Well if you want to maximize throughput from a single host to another node,
go with the 100 MB network.
But if you have 10 hosts that are constantly trying to send to a single host
go with the 10 x 10 MB networks.
An ethernet that is wired back to back between only two hosts (ala an
ethernet “null modem” cable) is very deterministic (but not perfectly so).
Several people are fighting problems with ethernet collisions right now. It
is well worth the investment in time to write some test utilities that will
perfectly simulate your worst case scenario and actually measure how bad
performance really is. That way when it coinsidently occurs in your normal
network it won’t catch you by surprise.
In writeing software for large systems I have spent almost as much time
writing software to prove that my ideas WON’T work as writing the software
that works. If you can’t punch holes in the software yourself, and you know
why it works, then random chance won’t break it either.
Bill Caroselli
“Alain Bonnefoy” <alain.bonnefoy@icbt.com> wrote in message
news:3B73998F.B648A39E@icbt.com…
I though about that because we are going to use intensively our qrtp
server but,
as I don’t know now if I will be able to connect it on the 100 MB network
because we are normally connected to it via 10/100 MB switches, I though
to use
2 or more network cards to connect our developpers on the different IP
adresses
of the server.just to have an idea, what’s the difference between one 100 MB network
access
and ten 10 MB network access with several client access at the same time?
An ethernet that is wired back to back between only two hosts (ala an
ethernet “null modem” cable) is very deterministic (but not perfectly
so).
There are no degrees of determinism. Either a system is deterministic
(i.e.
the worst case latency may be computed), or it is probabilistic
(only the
probability of occurrence of particular latencies may be computed). Of
course,
the scope of a deterministic system being discussed may be enlarged to
encompass a probabilistic component (at which point the system becomes
probabilistic).
Considering Ethernet as a system for transmission of a packet, when:
- wired back-to-back.
and - operating in full-duplex.
and - transporting a synchronous protocol.
it is fair to state that it is deterministic. That is to say, barring a
malfunction of the system as designed (i.e. a failure), the worst case
time
for a packet to be transmitted from one side of the connection to the
other
can be calculated, since all the relevant information is known (or can
be
obtained).
Several people are fighting problems with ethernet collisions right
now. It
is well worth the investment in time to write some test utilities that
will
perfectly simulate your worst case scenario and actually measure how
bad
performance really is. That way when it coinsidently occurs in your
normal
network it won’t catch you by surprise.
I am fighting this also, on the system I am working on here.
This system was developed by those who believed that only two of the
above
conditions needed to be met in order to insure deterministic behavior
from
Ethernet (they didn’t think they needed a synchronous protocol 
. Of
course,
the “collisions” that one suffers with an Ethernet system wired
back-to-back
and operating in full duplex, but with an asynchronous (rather than
synchronous)
protocol, are not wire collisions, but buffer collisions (either of
which
precludes determinism).
In writeing software for large systems I have spent almost as much
time
writing software to prove that my ideas WON’T work as writing the
software
that works. If you can’t punch holes in the software yourself, and
you know
why it works, then random chance won’t break it either.
I endorse this methodology.
it is a shame - but you are rigt !! 
Rennie Allen schrieb:
An ethernet that is wired back to back between only two hosts (ala an
ethernet “null modem” cable) is very deterministic (but not perfectly
so).There are no degrees of determinism. Either a system is deterministic
(i.e.
the worst case latency may be computed), or it is probabilistic
(only the
probability of occurrence of particular latencies may be computed). Of
course,
the scope of a deterministic system being discussed may be enlarged to
encompass a probabilistic component (at which point the system becomes
probabilistic).Considering Ethernet as a system for transmission of a packet, when:
- wired back-to-back.
and- operating in full-duplex.
and- transporting a synchronous protocol.
it is fair to state that it is deterministic. That is to say, barring a
malfunction of the system as designed (i.e. a failure), the worst case
time
for a packet to be transmitted from one side of the connection to the
other
can be calculated, since all the relevant information is known (or can
be
obtained).Several people are fighting problems with ethernet collisions right
now. It
is well worth the investment in time to write some test utilities that
will
perfectly simulate your worst case scenario and actually measure how
bad
performance really is. That way when it coinsidently occurs in your
normal
network it won’t catch you by surprise.I am fighting this also, on the system I am working on here.
This system was developed by those who believed that only two of the
above
conditions needed to be met in order to insure deterministic behavior
from
Ethernet (they didn’t think they needed a synchronous protocol >
course,
the “collisions” that one suffers with an Ethernet system wired
back-to-back
and operating in full duplex, but with an asynchronous (rather than
synchronous)
protocol, are not wire collisions, but buffer collisions (either of
which
precludes determinism).In writeing software for large systems I have spent almost as much
time
writing software to prove that my ideas WON’T work as writing the
software
that works. If you can’t punch holes in the software yourself, and
you know
why it works, then random chance won’t break it either.I endorse this methodology.
–
Dr. Jörg Kampmann - IBK-Consult for Real-Time and Embedded Systems
D-31228 Peine - Tel.:+49-177-276-3140 - Fax: +49-5171-13385
http://www.ibk-consult.de
===== QNX is the better Choice for Real-Time: http://www.qnx.com ====