| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 5483.1 | Response??? | OSLAGE::AGE_P | Aage Ronning, Oslo, Norway, (DTN 872-8464) | Wed May 07 1997 05:51 | 6 |
| 5483.2 | some answers | UTRTSC::KNOPPERS | Oswald Knoppers | Wed May 07 1997 06:41 | 30 |
| Not realy sure on your questions but...
A cluster alias (and in your case I guess you are talking about the
failover type op alias) is something you define on an interface.
>Q1. Could A+B+C+D be in the same alias and if so are there any rules about
> subnetting?
No.
>Q2. Could they have two different aliases: Alias_1 for A+B and Alias_2 for C+D
> and if so are there any rules about subnetting?
No.
>Q3. Could they have two different aliases: Alias_1 for A+D and Alias_2 for B+C
> and if so are there any rules about subnetting?
Yes, this is the way it works. In your case you have two ethernet rails, on
both rails you have an alias.
There are no specific rules for subnetting with regard to the alias.
About your other question. TCP/IP doesn't have the concept of messages
unlike DECnet (record oriented). With TCP you just send a stream of bytes
which is received as a stream of bytes.
Regards,
Oswald
|
| 5483.3 | PUSH flag? | OSLAGE::AGE_P | Aage Ronning, Oslo, Norway, (DTN 872-8464) | Wed May 07 1997 12:25 | 8 |
| 5483.4 | | UTRTSC::KNOPPERS | Oswald Knoppers | Wed May 07 1997 12:47 | 11 |
| >OK, but what's the PUSH flag used for? And how is that flag set?
Sorry, no idea. But, from .0:
>One system will write messages of variable length and they would like to be
>sure that a READ in the other end allways only reads that message and not a
>stream of data that could contain more than ONE message.
I think there is NO way with TCP to garantee this...
Oswald
|
| 5483.5 | I second .4 | LADDIE::TIBBERT | Lee Tibbert, DTN 226-6115 | Wed May 07 1997 18:26 | 25 |
| >>One system will write messages of variable length and they would like to be
>>sure that a READ in the other end allways only reads that message and not a
>>stream of data that could contain more than ONE message.
>I think there is NO way with TCP to garantee this...
I second .4's opinion. There is a way to do it with UDP for short messages.
Relying upon what gets read in a given I/O is poor programming
practice. The usual way is to place a higher level application
protocol on top of the TCP. Tag-Length-Value (TLV) protocols are
typical. A basic data communications text would describe the
three major methods of blocking data (I mean that to be helpful,
not as a put down.)
These days, I'd take an very strong look at HTML. It is not the
end all and be all, but it is exceptionally versatile.
Using a widely know, well exercised data transfer protocol saves
your customer all kinds of problems. Protocol design is easy
to get wrong and hard to get right. People have spent
a long time getting HTML right (and it still has some problems,
but less than the alternatives.)
Lee
|