Flow control , xin được bàn thêm về vấn đề này !!!

[velvetyrose]

Xin chào ,
Các bạn ơi, trong tầng Transport, Datalink và trong Frame Relay đều có chức năng điều khiển luồng Flow control. Vậy , về thực chất chúng hoạt động như thế nào ?
A` , ngoài ra Flow control , nó còn xuất hiện nhiều ở đâu nữa ?
Các bạn có thể nói thêm cho mình biết không ?

Flow control :?: Flow control :?: Flow control :?:
Hổng hiểu :( :evil: :shock:
Thân ,

[BlackTSB]

chào bạn mình có biết một só kiến thức về flowcontrol.Mình xin trả lời câu hỏi của bạn.Flow control hoạt động như thế nào thì bạn phải tìm các sách mà đọc vì nó rất dài kô thể nói hết ở đây được.Flow control có thể hoạt động ở cả lớp 2 và 4 tuỳ theo từng giao thức.Có 3 giao phương pháp Flowcontrol là stop-and-wait go-back-n và selective-repeat.Các flowcontrol này xuất hiện ở đâu nữa ư?ở bất cứ đâu còn lỗi và có khả năng sửa được lỗi.Hay nói cách khác ở trong tất cả các giao thức mạng

[velvetyrose]

Hi,

Flow control , mình luôn hiểu đó là điều khiển luồng thông tin, có nghĩa là truyền đi ít hay nhiều đó mừ .
Trong Frame Relay , có phải BECN, FECN... giữ chức năng điều khiển luồng , chắc vậy :?: :roll: :D
BlackTSB , stop-and-wait go-back-n và selective-repeat , nghe tên mình thấy nó cũng giống giống dạng hoạt động của BECN, FECN thì phải.
Mà ta cần Flow control chang han khi co congestion . Theo như BlackTSB nói, nó xuất hiện khi có lỗi , cái này chính là thuật ngữ Error Detecting , Error Correcting mừ. Vậy là bọn chúng liên quan ở đây ư ?
Cuối cùng, mình sẽ tìm sách chi, tìm ở đâu để đọc ? Cái này là quan trong nhất thì phải :?: :wink:

Thanks in advance !

-----------
Hu hu hu...
Tưởng là Flow Control cũng nhẹ nhàng, đơn giản. Ai ngờ "nó rất dài kô thể nói hết ở đây được" (trích từ thư của BlackTSB )!!!

[BlackTSB]

Hi.
Mình có một thời gian làm về lập trình Flow control nên cũng có biết chút ít.Theo mình biết ở trên mạng khái niệm sửa lỗi có nghĩa là TRUYÈN LẠI...tức là các lỗi đường truyền khi bị phát hiện thì sẽ được truyền lại chứ không phải là sửa lại.Còn việc congestion thì nó sẽ coi như là bị lỗi(quá time out trong flowcontrol cũng đồng nghĩa với viêc bị lỗi mà).Còn việc tron đường đi để tránh congestion thì là việc rất phức tạp và phải dựa chủ yếu vào việc định tuyến của router.Các sách về flowcontrol có rất nhiều,bạn thử xem qua "network computer","tcp/ip illustrated" và search trên mạng.Nếu bạn ở HN thì liên lạc với mình mình sẽ giúp.

[Present]

Theo mình thì các bạn đang bàn về những khái niệm sau:
- Phát hiện lỗi
- Cách sửa lỗi
- Điều khiển luồng

Phát hiện lỗi thì đa số được thực hiện bởi chức năng của trường kiểm lỗi có sẵn trong khung dữ liệu.

Sửa lỗi thì có thể khắc phục lỗi luôn thông qua trường kiểm lỗi (nhưng ko phải là lúc nào cũng có thể sửa được hết), ngoài ra có thể do timeout thì nó sẽ phát lại mà (cơ chế này bây giờ thường dùng).

Điều khiển luồng thì khác đây thực chất là cách làm để truyền dữ liệu trên đường đã chọn (đối với FrameRelay) được tối ưu nhất chứ. FrameRelay sử dụng FECN và BECN để thông báo tắc nghẽn. Trong FR luôn tồn tại một tốc độ cam kết. Khi truyền, mà không thấy thông báo tắc nghẽn thì nó sẽ tăng tốc độ đường truyền lên (nên nhớ rằng khi chỉ có một số ít thuê bao dùng đường truyền thì họ hoàn toàn có thể sử dụng cả phần băng thông của các thue bao rỗi). Nó sẽ tăng đến khi có thông báo tắc nghẽn thì lại hạ tốc độ xuống, quá trình này diễn ra như một quá trình động.
Đương nhiên là khi tắc nghẽn xảy ra quá lớn thì sẽ tạo nên tắc nghẽn cục bộ và đôi lúc tệ hơn nó có thể lan ra toàn mạng.

Trên đây là vài suy nghĩ của tôi, mong được biết thêm ý kiến của các bạn

[happyman_1x]

Hello all,
Theo mình biết thì flow control là flow control, error detection và error recovery là 2 vấn đề khác nhau chứ.
Flow control là điều khiển luồng, tức là thông báo, điều khiển đường truyền nhanh lên, chậm lại, tạm ngưng truyền, bắt đầu truyền. Luồng này được điều khiển căn cứ vào những tiêu chuẩn khác nhau tuỳ thuộc vào protocol truyền và mục đích. Chính vì vậy mà mình thấy flow control xuất hiện trên nhiều tầng khác nhau của OSI.
Thí dụ:
TCP: flow control ở tầng transport, nhằm mục đích tránh tràn buffer ngõ vào.
Frame relay: flow control ở tầng datalink, nhằm mục đích tránh tắc nghẽn trên đường truyền.
flow control giữa máy tính và modem : tầng physical , nhằm mục đích tránh tràn buffer.

Cám ơn Present đã mô tả flow control của frame relay, nó rất hay.

[BlackTSB]

to happyman_1x, :mình không nghĩ thế...thế mình hỏi bạn nhé window size là nằm ở phần nào?bạn sẽ thấy nó nằm ở cả 2 phần...Theo mình lập trình thì mình thấy 2 khái niệm đó tuy 2 nhưng được xử lí đồng thơì,hay nói cách khác nó được xử lí trong cùng một tiến trình với nhau.Với lại mình cũng muốn nói thêm là trong xử lí tín hiệu số khái niệm sửa lỗi là rất hạn chế.CHÚNG TA CHỈ SỬA ĐƯỢC LỖI KHI ĐƯỜNG TRUYỀN PHÁT SINH THÊM BIT,CÒN KHI ĐƯỜNG TRUYỀN KHÔNG PHÁT SINH THÊM BIT(CÓ NGHĨA LÀ CÁC BIT CHỈ THAY ĐỔI CHỨ KHÔNG PHÁT SINH THÊM) THÌ KHÔNG CÓ CÁCH NÀO SỬA ĐƯỢC LỖI,CHỈ PHÁT HIỆN ĐƯỢC LỖI.Đó là lí thuyết truyền tin đó.Có thể thấy ngay rằng sửa lỗi trong network có nghĩa là truyền lại tức là phải điều khiển luồng.ok?hai khái niệm này có mối liên hệ mật thiết với nhau do đó chúng sẽ được xử lí đồng thời với nhau.

[Present]

Hi BlackTSB


to happyman_1x, :.CHÚNG TA CHỈ SỬA ĐƯỢC LỖI KHI ĐƯỜNG TRUYỀN PHÁT SINH THÊM BIT,CÒN KHI ĐƯỜNG TRUYỀN KHÔNG PHÁT SINH THÊM BIT(CÓ NGHĨA LÀ CÁC BIT CHỈ THAY ĐỔI CHỨ KHÔNG PHÁT SINH THÊM) THÌ KHÔNG CÓ CÁCH NÀO SỬA ĐƯỢC LỖI,CHỈ PHÁT HIỆN ĐƯỢC LỖI.Đó là lí thuyết truyền tin đó.Có thể thấy ngay rằng sửa lỗi trong network có nghĩa là truyền lại tức là phải điều khiển luồng.ok?.

Theo mình bạn nói vạy là không chuẩn rồi.
Theo mình biết nếu sử dụng CRC trong khung dữ liệu thì có thể sửa được các lỗi bít đơn (lỗi bít kép thì không sửa được) cái này được áp dụng trung chuyển mạch gói X25 đó. Thời đó chất lượng đường truyền còn rất thấp nên mới dùng cách đó (sửa lỗi). và quá trình phát hiện lỗi cũng như sửa lỗi được thực hiện ngay tại các nút mạng mà nó đi qua.
Ngày nay chất lượng đường truyền đã tốt nên việc đó không còn cần thiết nữa. Ví dụ điển hình là FR, nó chỉ thực hiện việc phát hiện lỗi tại đích mà thôi, nếu sai thì sẽ truyền lại.

vả lại theo mình khi so sánh FR với OSI thì hình như FR tương ứng với tầng vật lý và tầng con MAC của tầng liên kết dữ liệu thôi mà.

[BlackTSB]

theo mình biết thì CRC chỉ được xử lí chủ yếu băng phần cứng và thực hiện ở lớp 2.Kha năng xửa lỗi của CRC là rất hạn chế,như bạn nói đó là chỉ sửa được có bit đơn trong khi MTU thường được default la 1500

[1''hpSky]

mình không nghĩ thế...thế mình hỏi bạn nhé window size là nằm ở phần nào?bạn sẽ thấy nó nằm ở cả 2 phần...Theo mình lập trình thì mình thấy 2 khái niệm đó tuy 2 nhưng được xử lí đồng thơì,hay nói cách khác nó được xử lí trong cùng một tiến trình với nhau

Vậy có khi bần lão cũng lập trình điều khiển luồng, rồi hứng lên lão xài 1+1 = 4, thế rồi lão kêu thế giới theo kiểu Control của lão, chắc chỉ có BlackTSB nghe !!



...trong xử lí tín hiệu số khái niệm sửa lỗi là rất hạn chế.CHÚNG TA CHỈ SỬA ĐƯỢC LỖI KHI ĐƯỜNG TRUYỀN PHÁT SINH THÊM BIT,CÒN KHI ĐƯỜNG TRUYỀN KHÔNG PHÁT SINH THÊM BIT(CÓ NGHĨA LÀ CÁC BIT CHỈ THAY ĐỔI CHỨ KHÔNG PHÁT SINH THÊM) THÌ KHÔNG CÓ CÁCH NÀO SỬA ĐƯỢC LỖI,CHỈ PHÁT HIỆN ĐƯỢC LỖI.

Thiện tai, thiện tai!!! Bần lão chưa nghe ai nói vậy. Hồng Thất Công Lão tiền bối còn biết CRC đa thức sinh bậc R có khả năng phát hiện và sửa các mọi lỗi đơn, mọi lỗi brust bậc <=R..., không hiểu lý thuyết error detection methods có gì thay đổi mà lão chưa kịp update??



Đó là lí thuyết truyền tin đó. Có thể thấy ngay rằng sửa lỗi trong network có nghĩa là truyền lại tức là phải điều khiển luồng.ok?

Làm sao OK được?? Sửa lỗi trong Network là phải truyền lại, tức là điều khiển luồng?? bần lão cho rằng đây là một câu điều kiện contrary to the real đó chớ: If error correction in the Network had had to retransmited packets, It would have been equal to the Flowcontrol ;)

[happyman_1x]

hi BlackTSB,
Theo mình thì window sizing là flow control chứ. Ta có thể nói như sau: bản chức của window sizing là flow control, căn cứ từ kết quả của reliable conection, mục đích là để dữ liệu trên đường truyền hiệu quả nhất.

Đồng ý với BlackTSB là flow control và error detection là có liên quan mật thiết với nhau, nhưng nó có khái niệm và chức năng khác nhau chứ. Khi lập trình bạn gom 2 thao tác này lại thành 1 tiến trình thì cũng không thể gọi 2 điều thành 1 được. Vì thật tế khi lập trình người ta vẫn thường gom nhiều chức năng lại thành 1 tiến trình khi nhận thấy như vậy sẽ tiện lợi hơn trong lập trình.

Đồng ý với BlackTSB là khả năng sửa lỗi trong xử lý tín hiệu số là rất hạn chế, CRC có thể sửa được lỗi, nhưng để CRC sửa được nhiều trường hợp lỗi bit thì cần phải tăng field CRC lên, điều này không hiệu quả cho đường truyền cũng như làm tăng thời gian xử lý. Đa số trường hợp là detect rồi yêu cầu truyền lại.


Có thể thấy ngay rằng sửa lỗi trong network có nghĩa là truyền lại tức là phải điều khiển luồng.ok?

Nhưng yêu cầu truyền lại đâu phải là điều khiển luồng ! điều khiển luồng bao gồm báo hiệu ngưng truyền, bắt đầu truyền, tăng tốc, giảm tốc chứ không có bao hàm yêu cầu truyền lại. Yêu cầu truyền lại là 1 phần của acknowlegement tức là đảm bảo reliable connection chứ !

[minhhieu_2002]

Các bạn đã tranh luân rất sôi nổi về Flow Control. Mỗi bạn nói về một vài ý. Thực ra nhũng thông tin về FlowContrrol thì rất nhiều nên tôi cũng không góp thêm nữa. Tôi chỉ có một ý kiến là: Trong việc truyền số liệu trên mạng, thuật ngữ FlowControl: tôi dùng là : Điều khiển lưu lượng.
(Chứ không phải điều khiển luồng). Mong các bạn cùng thảo luận.

[halh]

... Thực ra nhũng thông tin về FlowControl thì rất nhiều nên tôi cũng không góp thêm nữa.

Bạn không biết hay biết nhiều mà không muốn góp ý?? Nếu không biết thì nói thế là hơi quá đấy, còn biết nhiều mà không đưa ra ý kiến thì có được hay lắm phải không nhỉ??



Tôi chỉ có một ý kiến là: Trong việc truyền số liệu trên mạng, thuật ngữ FlowControl: tôi dùng là : Điều khiển lưu lượng.
(Chứ không phải điều khiển luồng). Mong các bạn cùng thảo luận.

Có gì phải thảo luận đâu nhỉ?? Không rõ minhhieu quan niệm hai từ traffic pattern và flow như thế nào??

Thiển nghĩ,

[pingpach]

Tôi thấy Halh nói quá rồi.
Minh hiếu nói thực ra tôi cũng chưa hiểu rõ lắm. nhưng tôi thấy Halh không có tinh thần trao đổi. Chúng ta vào diễn đàn này là để trao đổi học hỏi, chứ đâu có để chê bai nhau. Halh cứ thử đọc những bài của các cao thủ của diễn đàn mà xem, lịch sự và có văn hóa lắm.
Xin được góp ý! có gì không phải thì đừng để bụng nhé...hihihi

[BlackTSB]

Nhưng yêu cầu truyền lại đâu phải là điều khiển luồng ! điều khiển luồng bao gồm báo hiệu ngưng truyền, bắt đầu truyền, tăng tốc, giảm tốc chứ không có bao hàm yêu cầu truyền lại. Yêu cầu truyền lại là 1 phần của acknowlegement tức là đảm bảo reliable connection chứ !

trong yêu cầu truyền có truyền lại 1 gói,cả 8 gói hoặc chỉ truyền lại những gói bị hỏng,vậy mục đích của nó làm gì?là để giảm thiểu số truyền lại,tối ưu hóa đường truyền.Còn việc tăng tốc,giảm tốc đường truyền thường được gửi kèm theo trong ACK.Vả lại khái niệm tăng tốc giảm tốc trong mạng cũng không rõ ràng,chỉ có khái niệm truyền nhiều hay ít.Việc truyền nhiều hay ít trước kia bị hạn chế bởi buffer của hệ thống.Nhưng bây giờ các buffer thường rất lớn(lớn hơn rất nhiều khả năng truyền của mạng)nên vấn đề tràn bộ đệm là không xảy ra.Vậy mình muốn hỏi lại bây giờ cái gì sẽ có ý nghĩa quyết định đến việc điều khiển luồng?
Mình đồng ý với present rằng trong các môi trường truyền hiện nay thì tỉ lệ lỗi là rất thấp,theo mình biết với CAT5 UTP thì tỉ lệ lỗi là 10mũ(-7) còn cáp quang là 10mũ(-12).Với tỉ lệ lỗi nhỏ như vậy thì việc truyền lại khi phát hiện lỗi sẽ nhanh hơn nhiều so với việc bắt máy phải kiểm tra CRC và sửa lỗi trong mỗi gói tin.
Kiến thức của mình còn hạn chế vì vậy rất mong nhận được ý kiến đóng góp của các bạn.

[neoII]

Hi all.

Theo như mình đã học (hồi mấy năm trước ), thì trong mô hình OSI có 2 lớp cung cấp công việc data-flow control và CRC là transport và data-link. Tuy nhiên, cần phân biệt rõ chức năng của 2 lớp này.

1) Lớp Transport chủ yếu là do software thực hiện, cho nên việc data-flow ở đây rất hạn chế, ngược lại CRC mới là chính. Nhưng mức độ CRC phụ thuộc vào công nghệ mạng và giao thức mạng.

Ví dụ: SPX hoạt động tại lớp Transport, SPX sẽ truyền lại các gói tin bị hư hay bị lỗi cho đến khi nào gởi thành công thì thôi.

2) Lớp Data-link do thiết bị card mạng (NIC) thực hiện, do vậy việc data-flow control đúng nghĩa là diễn ra tại đây.

[BlackTSB]

Mình chưa bao giờ thấy thực hiện CRC ở lớp transport cả.Các sách mình đọc đều thực hiện CRC ở lớp datalink hết.Hồi mình làm card mạng bằng con 8051 cũng làm CRC bằng hardware ở lớp datalink luôn.Vậy nếu sách nào có nói CRC được sử dụng ở lớp 4 thì bạn chỉ cho mình xem với.Thanks

[neoII]

BlackTSB, bạn nói đúng. CRC có thực hiện ờ data-link là "một phần tất yếu của DataLink" nhưng CRC linh hoạt nhất là thực hiện tại lớp transport.

Theo lý thuyết là vậy hìhì chính xác thì mình không cần quan tâm tìm hiểu sâu đến vấn đề này cho lắm.

[Present]

Hi

Theo mình hiểu thì:

Điều khiển luồng tại lớp 2 được thực hiện tại các nút mạng mà gói dự liệu đi qua thôi (tránh bị tắc nghẽn tại các nút mạng khi nó tìm địa chỉ MAC cho bước tiếp theo để chuyển mạch dữ liệu). Đây là tránh tràn khung.
Điều khiển luồng tại lớp 4 chỉ được thực hiện tại hai nút đầu cuối mà thôi (nguồn và đích). Đây là trách tràn segment.

Mong được chỉ bảo thêm

[happyman_1x]

theo ý Present thì ethernet có flow control à ???? Vậy Present mô tả flow control ở ethernet cho mọi người biết với.

[Present]

Hi all!

Theo tôi nghĩ thì: Khi data được gửi đi thì nó sẽ được đóng thành gói rồi khung và cuối cùng sẽ chuyển thành các bít và truyền đi. Tại một nốt (hoạt động lớp 2) thì nó sẽ phải bóc dữ liệu ra để đọc MAC add của bước tiếp theo trên đường đi đến đích. Khi dữ liệu đến, thì nó sẽ được tổng hợp thành các khung dữ liệu thì các khung này cũng được lưu vào bộ đệm để chờ xử lý.
Ví dụ FR sử dụng FECN và BECN để hạn chế lưu lượng chuyển tới nút đó để nó có thời gian xử lý. Ngoài ra các khung co bít DE đặt lên 1 thì khi tắc nghẽn các khung này sẽ được hủy bỏ.

Mong chỉ bảo thêm!

[BlackTSB]

mình thì chưa nghe thấy ai bảo là thực hiện flow control ở lớp 2 của enthernet cả.Minh chỉ thấy các sách nói là thực hiện ở lớp 2 của các giao thức trong WAN như HDLC,FRAME RELAY...kô biết mình nói như vậy có đúng không?

[Present]

CRC có thực hiện ờ data-link là "một phần tất yếu của DataLink" nhưng CRC linh hoạt nhất là thực hiện tại lớp transport.

Theo lý thuyết là vậy hìhì chính xác thì mình không cần quan tâm tìm hiểu sâu đến vấn đề này cho lắm.

Bạn có thể chỉ giùm lý thuyết đó cho mình không vậy??????

[minhtit]

Hi all,

Tôi cho rằng phải thống nhất khái niệm "thế nào là Flow Control" trước đã. Tôi xin phép được dẫn ra đây định nghĩa đơn giản của Cisco :"Flow control is the process of controlling the rate at which a computer send data..." (CCNA 640-607 Certification Guide, page 102).

Nếu hiểu theo đúng định nghĩa này thì tôi cùng quan điểm với happyman_1x. Theo đó thì việc yêu cầu truyền lại không được coi là "Flow control", vì nó không tác động được gì đến "rate" của data cả. Tôi nghĩ rằng nên phân biệt rạch ròi các khái niệm Error detection / Error correction / Sequence Control / Flow Control.

Trong các khái niệm trên thì chỉ duy nhất Flow control là đề cập đến việc điều khiển "rate" của mạng (qua các cơ chế như BECN/FECN - trong FR-, windowing...). Việc truyền lại chính là do "Sequence control" đảm nhận (go-back-n, selective repeating...). Việc này nhiều khi chẳng liên quan gì đến việc "Error detection" hay "Error correction", ví dụ như thấy thiếu gói tin (vì một lý do nào đó) thì yêu cầu truyền lại thôi.

Tuy nhiên tôi cho rằng blackTSB hoàn toàn hiểu điều này, chỉ có điều là "định nghĩa" hơi khác thôi. Việc tranh luận từ ngữ có thể không quan trọng, miễn là mọi người hiểu đúng bản chất vấn đề.

Vài lời ngắn ngủi tham gia, thân chào.

[m160]

Hi BlackTSB
Theo nhu ban noi, "da tung lap trinh ve ky thuat nay", Tuy nhien minh thay ban phat bieu cu "the nao" ay...!...Ban lap trinh cac tien trinh xu ly song song hay khong, do la viec cua ban....Tuy nhien Flow Control la Error Correction la 2 ky thuat dung de giai quyet 2 van de hoan toan khac nhau ban a.!..
- Flow Control giai quyet van de tat nghen trong mang.
- Con Error Correction giai quyet viec truyen bi loi....

CRC chi la mot trong nhung thuat toan dung de sua loi. Nhuoc diem cua CRC la chi phat hien va sua duoc 1 loi
Phat hien sai nhieu bit thi phai truyen lai.. OK…chinh xac..!.. Tuy nhien chuyen do co lien quan gi den Flow Control chu???
Mot van de nua….em chi nghe noi :thong thuong truyen Data bi loi bit la do anh huong cua Physical Layer, tuc la do moi truong truyen dan
khong tot, lam cho signal bi distort…
Ngoai tru he thong PDH, chen them mot so bit gia de can bang phase giua 2 dau, em chua tung nghe qua hien tuong he thong sinh ra loi do tu dong chen bit vao ca….hehe.

[xd04cd01]

Cái này thuộc về tầng Transport trong mô hình OSI bạn xem sile của cisco về tầng transport sẽ rõ