link 2 computer

Dung lượng ở đây ý bạn nói là dung lượng file hay dung lượng truyền? vd với tốc độ 9.6kbps thì dù truyền 1 file mất cả ngày thì thời gian giữa 2 bit của byte dữ liệu cũng chỉ là 1,4ms thôi.
Tất nhiên trong truyền thông thì phải điều khiển luồng và lỗi. Nhưng chỉ link 2 host qua cổng RS-232 với cáp null-modem thì không cần đến mức như vậy, tôi sử dụng cáp null modem để giao tiếp với mcu51 và điều khiển truyền qua modem với các lệnh Hayes và rất đơn giản.
Tất nhiên là phải thiết lập cổng cho chuẩn, đúng chân. Còn điều khiển luồng như thế nào là do 2 tiến trình 2 phía tự quyết định.
Bạn nối chân RST và CTS hay dùng xon/xoff để điều khiển mà chương trình không bạn không sử dụng đến thì làm sao đk luồng được.
Cách đơn giản như mình nói ở trên có thể sử dụng cho bất kỳ kích thước file nào, vì dung lượng truyền ở đây là tốc độ cổng COM, không có ý nghĩa gì so với tốc độ xử lý của máy tính

Có 1 cách để kiểm tra cách truyền file giữa 2 PC:
Sử dụng Hyper terminal cấu hình cổng COM, Baud Rate=9600, Flow control= none, no parity, 1 stop bit trên cả 2 PC nối nhau qua cáp null modem ( chỉ cần Tx, Rx và GND).
Sau đó vào menu chọn Send text file bên PC này thì tại cửa sổ Hyper bên kia sẽ hiển thị toàn bộ nội dung file nhận được.
Trong thực tế tôi đã sử dụng cáp null-modemđể link 2 LAN của 2 phòng KCS 2 xưỏng trong 1 nhà máy thông qua adapter RS232 <-> RS485 (tự chế ), và 2 PC chạy linux, vì 2 xưởng quá xa so với cáp UTP nhưng sử dụng modem qua PABX thì quá tội.
Dữ liệu trên đường cáp null modem này là các luồng TCP/IP (PPP) chứ không đơn giản chỉ là file ASCII.

Bác có vẻ rành về khoản này nhể
Cho em hỏi tẹo vậy:
Trước em cũng chơi kiểu trần trụi nối trâu đất không cần điểu khiển luồng lạch gì cả, cũng bị toi vì không nhận được dữ liệu (thiếu mất vài khúc ). Nhưng sau phải kiếm quyển sách nghiên cứu HDLC để viết lại cẩn thận thì nhận được -> Em nghĩ do có phần điều khiển luồng nên mới ăn được. Chả biết có đúng không?
Bác dùng TCP/IP thì ổn quá còn gì. Nó cũng đã có điều khiển luồng xịn đấy thôi. Có ở TCP rồi nên tầng Datalink nó không quan tâm -> Không có vẫn tốt.
Còn lệnh AT với modem : Em nghĩ mấy cái lệnh ngắn ngủn đấy so thế nào với đống dữ liệu hàng chục MB. Cái dung lượng em nhắc ở trên là cả dung lượng file và tốc độ truyền (Ai lại truyền 60Mb ở tốc độ 9.6 k )
Lỗi em hay gặp khi bắt đầu truyền file kích thước khoảng 5 Mb trở lên. Không rõ là do máy xử lý hay do sai số gì? Nhưng hết sau khi có điều khiển luồng nên từ đó em cũng không nghĩ ra được lý do gì cả? Bác có thể chỉ thêm không. Tiếc là không còn giữ mấy cái thời trai trẻ để bác xem
Bác nói hộ em luôn cái Hyper Terminal hoạt động thế nào nhé? Em nghĩ thằng này không chỉ đơn giản gửi qua cổng Com bình thường. Liệu nó có dùng thêm giao thức điều khiển luồng khi bác gửi file không?
Được cid sửa chữa / chuyển vào 12:24 ngày 25/03/2004

HDLC cho phép điều khiển lỗi bằng từ checksum, mình không rõ khi lúc bạn viết chương trình theo giao thức HDLC bạn có chú ý đến nó không. Điều khiển luồng thì có rất nhiều cách khác nhau nhưng đối với rs-232 thì chỉ là thông báo sẵn sàng nhận hay chuẩn bị phát.
Truyền file qua cổng Com chuẩn như Xmodem, Zmodem... thì có cả điều khiển luồng và lỗi và mã chương trình có rất nhiều lắm.
Mình nói như trên vì mình nghĩ là chỉ đơn giản chỉ là giao tiếp thông thường. Nếu với file có kích thước lớn và truyền với tốc độ cao thì phải tham khảo các giao thức của xmodem...
Hyper dùng với rất nhiều cách như làm consol config các thiết bị, giao tiếp mạng qua telnet hay ftp, ssh... cái đó thấy ngay khi khởi động.
Còn TCP/IP qua cổng COM như mình nói thì đó là giao thức PPP mà các gói IP được gói trong các khung HDLC như bạn biết. Bạn tham khảo các RFC trên mạng thì chi tiết hơn.
Thời sv mình cũng hay dùng C để viết các chương trình như bạn . Còn bây giờ mình dùng Hyper để cấu hình các thiết bị viễn thông cũng như router.

Tôi chưa truyền file lớn(>100M) như vậy lên chỉ thêm vài ý thôi :
- Đúng là có điều khiển luồng, nhưng dùng HDLC làm quái gì, phức tạp !
- Nếu dùng đối tưọng truyền thông MSCOMM32 của MS thì nên quên nó đi trong trường hợp này : Các thông số "tươi" bộ đệm thu/phát của nó không ổn lắm, mà hình như bạn cũng quên công việc xoá đệm hay sao đấy ! ( vả lại PC đọc / ghi lâu quá cũng phải nghỉ uống nước chè chứ).
- Tự làm lấy thích hơn : tự tạo MSCOMM khác, định nghĩa lại các thông số của DCB (timeout, ..) cải tiến menthod phát : Phát đi một khối dữ liệu như kiểu Send_stream của mạng chứ không chơi phát string cổ lỗ sĩ có sẵn ! Code DCB bằng delphi hay VB có nhiều trên mạng.
Tại sao lại không thử nhỉ ?

HDLC là 1 trong các giao thức chuẩn tầng liên kết dữ liệu của CCITT và ISO cho các thiết bị truy nhập mạng. Các ks sư lập trình hệ thống phải tham khảo giao thức này khi viết các firmware cho thiết bị (vd như router). Biết thêm HDLC đâu có thừa, nó cũng không quá khó mà.
Giao tiếp chơi thì viết sao cũng được, không cần chuẩn. Nhưng nếu tham gia vào các hệ thống hiện có, thì cần phải theo chuẩn. HDLC là 1 giao thức chuẩn rất phổ biến.
MScomm32 là 1 ocx trong thư viện Visual Studio để truy cập cổng COM. Khi là sv, mình thường cùng với các bạn bè khoa Tự động hoá dùng VC++ để viết các chương trình mô phỏng hệ thống thông qua cổng com và lpt nên cũng biết đôi chút về mscomm.
Nếu viết bằng Java thì có thể quên mscomm đi.
Stream là cách gọi luồng dữ liệu nối tiếp tuần tự trao đổi giữa các process trong các hệ thống đa nhiệm và cũng là 1 kiểu định nghĩa trong các ngôn ngữ hướng đối tượng, Trong khi string là kiểu định nghĩa chuỗi các ký tự ASCII trong ngôn ngữ C.
==> Stream không phải là cải tiến của "string cổ lỗ sĩ".

Bác opentdoors đúng là giỏi HDLC quá. Nếu biết về FR hay X25 thì chắc bác cũng đem áp dụng quá.
Sếp ở chỗ bác dễ tính nhể ? Ở chỗ em ngày xưa có một tên được mời công tác chỗ khác do đưa ra giải pháp link 2 PC như bác. Không biết bác có quen người này không ?
Thực hiện một vấn đề thì có nhiều giải pháp. Vấn đề ở đây là chọn cách đơn giản hoá + tối uư.
Không nên bằng lòng với mỗi một thứ mình biết. Phải mở mang đầu óc đi chứ.
Ngày xưa chắc bác giỏi Pascal và Tubo C 3.0 lắm nhể ?
Được vtpl sửa chữa / chuyển vào 14:45 ngày 28/03/2004
Được vtpl sửa chữa / chuyển vào 14:57 ngày 28/03/2004

Mình chả ưa gì những kẻ nói vuốt đuôi, đọc lại từ bài đầu đi.

Bác này đã biết ở chỗ bác opendoors điều kiện là thế nào chưa mà đã phán là dùng HDLC ở đó là không đơn giản hoá hay tối ưu nhỉ?
Không biết bác đã hiểu được là người ta hiểu được những cái cơ bản, đơn giản rồi mới có được kiến thức phức tạp, có kiến thức phức tạp mới làm được sản phẩm đơn giản.

Thực ra chúng ta đang tham gia vào diễn đàn link giữa 2 PC, trong đó dùng cổng com là 1 cách đơn giản và tiện dụng nhất, rồi từ đó nói đến các vấn đề khác liên quan đến trao đổi data giữa 2 PC qua cổng com.
Tôi chẳng tin 1 người rất giỏi lập trình mà lại không biết Pascal, hay C. Cũng như ai đó so sánh X25 hay FR với HDLC.