| |
PA2AGA > TCPDIG 06.12.96 13:12l 211 Lines 7543 Bytes #-10797 (0) @ EU
BID : TCP_96_244
Read: DG7DAH GUEST
Subj: TCP-Group Digest 96/244
Path: DB0AAB<DB0MWS<DB0RBS<DB0HOM<LX0PAC<ON7RC<ON4AWP<ON1CED<ON4KTK<F8KOT<
F5MJS<F1HPZ<F1NWC<F5KGR<F6KIF<F6PTT<F5MSQ<F8KKV<F5ROC<F1HAQ<F5SLQ<
SK7CA<SM7RME<SK7AF<SM5SUH<SK5AS<SK5BN<SK5UM<SK5AE<SK5BB<SK4HC<SM4TFE<
SK4KS<SK4WV<SM4TYA<SM3ESS<SK3BG<SK3EK<SK3LH<SK2AT<OH6RBG<OH6RBI<OH6RBC<
OH6RDP<OH6RBT<OH1RBF<OH1RBU<OH1RBD<OH2RBJ<OH2RBI<OH7RBA<PI8VNW
Sent: 961117/1159Z @:PI8VNW.#ZH2.NLD.EU #:41348 [Hoek v Holland] FBB5.15c
From: PA2AGA@PI8VNW.#ZH2.NLD.EU
To : TCPDIG@EU
Received: from pa2aga by pi1hvh with SMTP
id AA20788 ; Sun, 17 Nov 96 11:44:43 UTC
Received: from pa2aga by pa2aga (NET/Mac 2.3.62/7.1) with SMTP
id AA00008159 ; Sun, 17 Nov 96 12:23:28 MET
Received: from pa2aga-1 by pa2aga with SMTP
id AA00008140 ; Sun, 17 Nov 96 12:18:04 MET
Received: from pa2aga-1 by pa2aga-1 (NET/Mac 2.3.62/7.5.5) with SMTP
id AA00008508 ; Sun, 17 Nov 96 12:18:02 MET
Date: Sun, 17 Nov 96 12:13:42 MET
Message-Id: <tcp_96_244>
From: pa2aga
To: tcp_broadcast@pa2aga-1
Subject: TCP-Group Digest 96/244
X-BBS-Msg-Type: B
TCP-Group Digest Sat, 16 Nov 96 Volume 96 : Issue 244
Today's Topics:
Broadcast TCP/IP packet
File loss (3 msgs)
Net 44 routing (2 msgs)
TCP-Group Digest V96 #241
Send Replies or notes for publication to: <TCP-Group@UCSD.Edu>.
Subscription requests to <TCP-Group-REQUEST@UCSD.Edu>.
Problems you can't solve otherwise to brian@ucsd.edu.
Archives of past issues of the TCP-Group Digest are available
(by FTP only) from ftp.UCSD.Edu in directory "mailarchives".
We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party. Your mileage may vary. So there.
----------------------------------------------------------------------
Date: Fri, 15 Nov 1996 16:18:17 -0600
From: "Milton D. Miller II" <miltonm@bga.com>
Subject: Broadcast TCP/IP packet
On Tue, 12 Nov 1996 at about 18:21:09 -0700 (MST),
Bill (wa7nwp@wa7nwp.ampr.org) asked:
> Is there any existing protocol/RFC detailing how an IP
> packet (DG or VC) would be sent to a destination yet be read,
> logged, displayed or acted on somehow by all IP systems hearing
> it on the way?
You mean IP multicast?
(Ok, what are the suggestions for the layer above? UDP? Others??)
(I looked at it before, but haven't played with it yet. I have
some notes where others are looking also).
milton
--
Milton Miller KB5TKF miltonm@bga.com
------------------------------
Date: Wed, 13 Nov 1996 14:04:26 -0800 (PST)
From: Phil Karn <karn@unix.ka9q.ampr.org>
Subject: File loss
>The disk on-board cache can also be bypassed with any modern disk technology.
>For example, a SCSI "WRITE" command with the "FUA" ("Force Unit Access") bit
Do these in-disk caches really operate in a delayed write-back mode?
If so, don't they "sync" delayed writes a la UNIX? It would seem
rather irresponsible to design a drive that didn't do this.
Phil
------------------------------
Date: Fri, 15 Nov 1996 13:08:49 +0000 (GMT)
From: Alan Cox <alan@cymru.net>
Subject: File loss
> Do these in-disk caches really operate in a delayed write-back mode?
Some do especially when doing multiblock I/O. The CPU<->disk interface
in PIO mode 3 and 4 is faster than the head speed of the disk so they have
to delay write back a little anyway. Some take that a tiny bit further.
> If so, don't they "sync" delayed writes a la UNIX? It would seem
> rather irresponsible to design a drive that didn't do this.
They do write back over a couple of seconds time, but if you lose power
at an annoying moment you lose data. And we all know what 2 seconds the
power will go off dont we.
Alan
------------------------------
Date: Mon, 11 Nov 96 15:23:00 -0000
From: mikebw@BILOW.BILOW.UU.IDS.NET (Mike Bilow)
Subject: File loss
Karl F. Larsen wrote in a message to Mike Bilow:
KFL> Thought it might be time to remind every one that
KFL> the operating systems we are using keep files open in RAM.
KFL> When a power loss or crash happen those files in ram are
KFL> lost. This looks like files were changed, which they are,
KFL> but not by you.
KFL> Operating systems like this are Linux, Win-95 and
KFL> Windows NT. I am certain that JNOS in win-95 could be
KFL> effected but if it's windows 3.1, then it is a mystery since
KFL> that software doesn't allow open files. But Windows 3.1 will
KFL> write to ram on top of running programs that can cause
KFL> strange results.
This is not techically true about Linux or OS/2. While reads and writes are
cached by default in these operating systems, both have a timer task which
periodically commits information to disk; Linux ext2fs calls this "update"
while OS/2 HPFS calls this the "lazy writer." The time interval can be set
explicity, but it usually defaults to about 5 seconds. Both can also detect
whether the filesystem was last closed gracefully or not, and can usually
recover files open when the filesystem was closed ungracefully.
Windows NT is a special case since its filesystems run without privilege.
This
is like using a really big fuse for better protection -- of the fuse. NTFS is
nominally a "journaling" filesystem which maintains a transaction history for
uncommitted filesystem operations, so its intended behavior when the
filesystem
is closed ungracefully is to throw away all uncommitted filesystem operations
and return to its "last known good" point. The drawback is that this could be
file open time or anything else.
Filesystem operations are exactly the same in Windows 3.1x and Windows 95,
except that Windows 95 has essentially the same added VxDs as provided "32-bit
File Access" in Windows for Workgroups 3.1x. In all three of these systems,
including Windows 95, VxD space is globally accessible by any renegade
process.
To be clear about this, Windows 95 does prevent 32-bit Ring 3 processes from
trampling on each other, but does not prevent them from trampling on critical
Ring 0 system areas such as the disk managers. The new and incompatible
"FAT32" being slipstreamed into the OEM version of Windows 95 makes no
improvement here, except that it makes the cached FAT a bigger target for
renegade processes.
-- Mike
------------------------------
Date: Fri, 15 Nov 1996 06:39:51 -0800
From: brian@nothing.UCSD.EDU (Brian Kantor)
Subject: Net 44 routing
Yes, there was a routing problem. It has been taken care of.
- Brian
------------------------------
Date: Fri, 15 Nov 1996 04:03:41 -0600
From: "Steve Sampson" <ssampson@oklahoma.net>
Subject: Net 44 routing
Someone said net-44 was a Turkey, and this dweeb in the 4th cubicle
from the end thought they said it *was* in Turkey...
Just kidding,
Steve
----------
> I've seen the routing for Net 44 messed up at Sprint a couple of times in
> the last week. Anybody else seeing Net 44 being routed to Turkey?
------------------------------
Date: Tue, 12 Nov 96 14:51:22 +0100
From: iw1cxz@ik1xht.ampr.org (Andrea Borgnino)
Subject: TCP-Group Digest V96 #241
unsubscribe
( ( | ) ) Fight
| And_Bov Email: iw1cxz@pc10.cisi.unito.it For
/_\ Web http://www.cisi.unito.it/radiogw/and_bov Free
/\_/\ My Fanzine : http://www.alpcom.it/hamradio/freewaves Radio
!
Radio .. live trasmission, listen to the silence , let it ring on..
Joy Division - 1979
------------------------------
End of TCP-Group Digest V96 #244
******************************
You can send your message for this bulletin
to: tcp-group@pa2aga on .AMPR.ORG-net
or: tcpaga@pi8vnw.#zh2.nld.eu on BBS-net
------
NOT TO: pa2aga@pa2aga or pa2aga@pi8vnw.#zh2.nld.eu PLEASE!!
It will get posted automatically within a few days
Read previous mail | Read next mail
| |
