[IP-SFS] Protokoll Überlegungen (mit Einfluss auf das Interface)

[Jogi Hofmüller]

Hoi!

Da ich grad das RFC ins CVS repository eingecheckt hab und dabei ein
paar Fehler korrigierte, hab ich weiter überlegt und mir folgende
Frage(n) gestellt.

Ad 'commit ip frame'

 Brauchen wir eigentlich die Fahne Z (IEN - Ip frame ENd) und den
 korrespondierenden Befehl im Interface? Sollte es nicht dem IP-SFS
 Treiber (dem Interface) obliegen draufzukommen, wann ein ip-frame zu
 Ende ist?

 Die Anzahl der zu übertragenden Blöcke pro ip-frame steht doch gleich
 am Beginn der Transmission fest wenn ich nicht irre. Also könnten wir
 im Protokoll vorsehen, dass nach vollständiger Übertragung einer
 Sequenz von N Blöcken ein ip-frame vollständig übetragen ist und an den
 IP Stack übergeben wird? Damit sparen wir ein zu definierendes Signal
 und schaffen Klarheit, oder?

Ad Flow Control (?)

 - Solange ein Interface (eine Seite) spricht, hat die andere Pause und
   ist mit Lesen/Hören beschäftigt.
 - Sobald BEN vom Sender übertragen wurde, wartet Sender N
   Sekunden/Minuten timeout auf BAK. Nach verstreichen des timeouts ohne
   BAK wird der Block wiederholt.
 - Sobald eine Sequenz (ein ip-frame) vollständig übertragen ist, MUSS
   ein neuer Handshake erfolgen (RTS/RTR), denn es könnten theroretisch
   auf beiden Seiten ip-frames in der send-queue warten, oder?

Ad Retransmissions

 RFC 761 ist bestenfalls vage über timeout Werte. Es heisst u.a. im
 folgenden Absatz is timeout z.b. IMHO optional:

  The timeout, if present, permits the caller to set up a timeout for
  all buffers transmitted on the connection.  If a buffer is not
  successfully delivered to the destination within the timeout period,
  the TCP will abort the connection.  The present global default is 30
  seconds.  The buffer retransmission rate may vary; most likely, it
  will be related to the measured time for responses from the remote
  TCP.

   [RFC761 page 44]

 Zeitangaben finden sich äusserst selten und sind meist willkürlich
 definierte Werte. IMHO sollte es also keine Verletzung des Standards
 sein, diese Werte zu redefinieren ;) Konkret wären das z.B. TTL (1
 Minute) und MSL (2 Minuten).

 Ansonsten sähe ich kein Problem darin, ein Segment dessen sequence
 number wir bereits kennen einfach zu verwerfen ... ;) Über sowas wie
 MAX retransmissions hab ich nix konkretes gefunden ...
 
Im RFC hab ich ausserdem ein paar Sachen verändert. Unter anderem den
'nipple' zum 'nibble' gemacht (HalfByte) ;) und ein paar Fahnenbilder
die echt falsch waren korrigiert.

Current Version RFC: http://was.mur.at/fisch/rfc/

Soviel für heute. Ich bin am Grübeln ;)

Gruss,
j.
-- 
Jogi Hofmueller |*|    ICQ: 284632332
                |*| key id: B972CEC1 
                |*| random.sks.keyserver.penguin.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.mur.at/pipermail/ip-sfs/attachments/20060423/66356a9d/attachment-0002.pgp