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]

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

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]

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

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]

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

... 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]

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

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.