Đối với hầu hết các hệ thống nhúng, chi phí thường là một nhân tố giới hạn. Nhân tố này ràng buộc các tài nguyên sẵn có như RAM và khả năng xử lý. Vì vậy, nhiều hệ thống nhúng không có nhiều hơn vài kilobyte bộ nhớ RAM.
TCP/IP thường được xem là quá nặng để có thể thực thi trên một hệ thống nhỏ như các node cảm biến. Nhưng thực tế đã chứng minh rằng thậm chí một hệ thống nhỏ cũng có thể chạy bộ giao thức này mặc dù có chất lượng thấp hơn về mặt lưu lượng. uIP được thiết kế để có thể sử dụng bộ giao thức TCP/IP trên vi xử lý nhỏ 8 bit. Thực hiện TCP/IP uIP chỉ chiếm vài kilobyte của không gian mã, yêu cầu vài trăm byte bộ nhớ RAM và đã thực hiện thành công trên bảng mạch cảm biến nhúng (ESB). ESB [10] được trang bị với một số cảm biến, một bộ thu - phát vô tuyến và một bộ vi điều khiển 8 bit năng lượng thấp MSP430 với 2048 byte RAM và 60 kilobyte flash ROM.
2.2.4.1 Giới thiệu uIP
Bộ giao thức Micro IP (uIP) [8] được phát triển bởi Adam Dunkel trong nhóm các hệ thống mạng nhúng của viện khoa học máy tính Swedish.
Bộ giao thức uIP được viết bằng ngôn ngữ lập trình C và là bộ giao thức TCP/IP mã nguồn mở được phát triển riêng cho các bộ vi điều khiển nhúng bằng cách giảm thiểu bộ nhớ dữ liệu và mã. Các hệ thống nhúng sử dụng uIP có thể kết nối tới mạng nội bộ hoặc mạng Internet.
Giao thức uIP được thiết kế chỉ có một tập hợp tối thiểu tuyệt đối các tính năng sử dụng của bộ giao thức TCP/IP hoàn chỉnh. uIP chỉ xử lý một giao diện mạng đơn và tập trung vào các giao thức IP, ICMP, UDP, ARP và TCP.
Giả sử rằng TCP/IP tồn tại trong các hệ thống nhỏ luôn giao tiếp được với TCP/IP qui mô đầy đủ chạy trên các thiết bị mạng khác. Giả thiết này có thể loại bỏ một số cơ chế nhất định nhằm làm đơn giản hệ thống.
2.2.4.2 Vòng lặp điều khiển chính
Bộ giao thức uIP có thể hoạt động như một thao tác trong hệ thống đa nhiệm hoặc như một chương trình chính trong một hệ thống đơn nhiệm. Trong cả hai trường hợp, vòng lặp điều khiển chính lặp đi lặp lại nhiều lần hai bước:
1. Kiểm tra nếu một gói tin đến từ mạng 2. Kiểm tra nếu hết thời gian chờ định kỳ
Hình 2.10: Vòng lặp điều khiển chính
Nếu một gói tin đến, hàm xử lý lối vào - uip_input() được gọi bởi vòng lặp điều khiển
chính. Hàm xử lý lối vào sẽ không bao giờ bị chặn nhưng phản hồi đồng thời. Khi nó phản hồi, bộ giao thức hoặc ứng dụng của các gói tin đến được chỉ định có thể đã tạo ra một hoặc nhiều hơn các gói tin phản hồi. Nếu vậy, driver thiết bị mạng được yêu cầu để gửi đi các gói tin này.
Thời gian chờ định kỳ được sử dụng để điều khiển các cơ chế TCP phụ thuộc vào bộ định thời như báo nhận trễ, truyền lại và ước lượng thời gian khứ hồi. Khi vòng lặp điều khiển chính dự đoán bộ định thời tuần hoàn được khởi động, nó yêu cầu hàm xử lý bộ
định thời uip_periodic() của bộ giao thức TCP/IP. Vì bộ giao thức TCP/IP có thể thực
hiện truyền lại khi gặp các sự kiện định thời, driver thiết bị mạng được gọi để truyền đi các gói tin có thể đã được tạo ra.
2.2.4.3 Quản lý bộ nhớ
Trong cấu trúc uIP, RAM là nguồn tài nguyên khan hiếm nhất. Chỉ với một vài kilobyte RAM có sẵn cho bộ giao thức TCP/IP sử dụng, các cơ chế trong TCP/IP truyền thống không thể áp dụng trực tiếp.
Bộ giao thức uIP không sử dụng cấp phát bộ nhớ động. Thay vào đó, nó sử dụng một bộ đệm chung để lưu trữ các gói tin và có một bảng cố định duy trì trạng thái kết nối. Bộ đệm gói tin chung đủ lớn để chứa một gói tin với kích thước tối đa. Khi một gói tin đến từ mạng, driver thiết bị đặt nó vào bộ đệm chung và gọi bộ giao thức TCP/IP. Nếu gói tin bao gồm dữ liệu, bộ giao thức TCP/IP sẽ chuyển phát tới ứng dụng tương ứng. Vì dữ liệu trong bộ đệm sẽ bị ghi đè bởi gói tin đến tiếp theo, ứng dụng sẽ thực hiện ngay lập tức trên dữ liệu hoặc copy dữ liệu vào trong bộ đệm thứ hai cho quá trình sau. Bộ đệm gói tin sẽ không bị ghi đè bởi gói tin mới trước khi ứng dụng xử lý dữ liệu này. Các gói tin đến khi ứng dụng đang xử lý dữ liệu phải xếp hàng đợi bởi thiết bị mạng hoặc driver thiết bị. Hầu hết các bộ điều khiển Erthernet chip đơn có bộ đệm trên chip đủ lớn để chứa ít nhất 4 frame Erthernet kích thước tối đa. Các thiết bị được xử lý bởi bộ xử lý như là cổng RS232 có thể copy các byte đến tới bộ đệm riêng biệt trong quá trình ứng dụng xử lý. Nếu bộ đệm đầy, gói tin đến sẽ bị loại bỏ. Điều này có thể dẫn đến suy giảm chất lượng nhưng chỉ khi có nhiều kết nối chạy đồng thời. Điều này là do uIP thông báo một cửa sổ nhận rất nhỏ chỉ có một segment TCP đơn ở trong mạng cho mỗi kết nối.
Trong uIP, bộ đệm gói tin chung tương tự được dùng cho các gói tin đến cũng được sử dụng cho tiêu đề TCP/IP của dữ liệu ra. Nếu ứng dụng gửi dữ liệu động, nó có thể sử dụng các phần bộ đệm gói tin chung không dùng cho các tiêu đề như một bộ đệm lưu trữ tạm thời. Để gửi dữ liệu, ứng dụng sử dụng một con trỏ trỏ tới dữ liệu cũng như chiều dài của dữ liệu trong bộ giao thức. Tiêu đề TCP/IP được ghi vào bộ đệm chung và một khi tiêu đề được tạo ra, driver thiết bị gửi tiêu đề và dữ liệu ứng dụng vào mạng. Dữ liệu không được xếp hàng để truyền lại. Thay vào đó, ứng dụng phải sao chép lại dữ liệu nếu cần truyền lại.
Độ lớn tổng cộng bộ nhớ sử dụng cho uIP phụ thuộc nhiều vào các ứng dụng của thiết bị cụ thể nơi mà hệ thống hoạt động. Cấu hình bộ nhớ xác định cả lưu lượng tổng hệ thống có thể xử lý và số lượng các kết nối đồng thời tối đa. Một thiết bị gửi email lớn tại cùng thời điểm chạy web server với các trang web tự động cao với nhiều khách đồng thời sẽ đòi hỏi nhiều RAM hơn là chạy một server Telnet đơn giản. Có thể chạy hệ thống uIP
với ít nhất 200 byte RAM nhưng cấu hình như vậy cung cấp lưu lượng cực kỳ thấp và chỉ cho phép số lượng nhỏ các kết nối đồng thời.
2.2.4.4 Thực hiện
uIP liên quan chủ yếu đến giao thức TCP/IP. Các giao thức lớp trên được xem là một phần ứng dụng và các giao thức mức thấp được xử lý bởi driver của phần cứng mạng.
Các giao thức trong bộ giao thức TCP/IP được thiết kế theo mô hình phân lớp, trong đó mỗi giao thức thực hiện chức năng riêng và tương tác giữa các lớp giao thức được định nghĩa một cách chặt chẽ. Tiếp cận theo kiểu phân tầng là cách tốt nhất để thiết kế các giao thức nhưng không phải luôn là cách thực hiện các giao thức tốt nhất. Trong uIP, sự thực hiện giao thức được kết hợp theo cặp để tiết kiệm không gian mã.
Các yêu cầu chính thức đối với các giao thức trong bộ giao thức TCP/IP được chỉ rõ trong một số tài liệu RFC được công bố bởi tổ chức IETF. Một giao thức trong bộ giao thức được định nghĩa trong tài liệu RFC. RFC1122 tập hợp, hoàn thiện, hiệu chỉnh và bổ sung các tài liệu RFC để xác định các yêu cầu đối với các lớp truyền thông của các host Internet.
Các yêu cầu RFC1122 có thể phân chia thành hai loại: một loại giải quyết vấn đề truyền thông host tới host, một loại giải quyết vấn đề truyền thông giữa các ứng dụng và các giao thức mạng. Tất cả các yêu cầu về truyền thông host to host được thực hiện trong uIP. Tuy nhiên, một số yêu cầu về truyền thông giao thức - ứng dụng như cơ chế thông báo lỗi mềm và bít kiểu dịch vụ cấu hình động đối với kết nối TCP không được thực hiện để giảm kích thước mã.
uIP hỗ trợ các giao thức sau trong bộ giao thức TCP/IP: - Giao thức điều khiển truyền – TCP
- Giao thức Internet – IP
- Giao thức điều khiển bản tin Internet – ICMP - Giao thức UDP…
a, Giao thức Internet – IP (adsbygoogle = window.adsbygoogle || []).push({});
Khi các gói tin đến được xử lý bởi uIP, lớp IP là giao thức đầu tiên kiểm tra gói tin. Lớp IP thực hiện một vài kiểm tra đơn giản như địa chỉ đích của gói tin và trường checksum trong tiêu đề IP.
Lắp ráp các đoạn IP
Việc lắp ráp các đoạn IP được thực hiện bằng cách sử dụng các bộ đệm riêng biệt lưu trữ các gói tin để lắp ráp. Một đoạn tin đến được copy vào đúng vị trí trong bộ đệm và một sơ đồ bít (bit map) để theo dõi các đoạn tin được nhận. Bởi vì byte đầu tiên của một đoạn tin IP được sắp hàng trong giới hạn 8 byte, sơ đồ bít yêu cầu một lượng bộ nhớ nhỏ.
Khi tất cả các đoạn tin được lắp ráp, gói tin IP tổng được chuyển lên lớp giao vận. Nếu tất cả các đoạn tin không được nhận trong một khung thời gian nhất định, gói tin sẽ bị loại bỏ.
Hệ thống xử lý uIP chỉ có một bộ đệm đơn để giữ các đoạn tin cần lắp ráp vì vậy không hỗ trợ lắp ráp đồng thời nhiều hơn một gói tin. Vì các gói tin được lắp ráp không thông dụng nên điều này là hợp lý.
Broadcast và multicast
IP có khả năng quảng bá (broadcast) và phát đa điểm (multicast) các gói tin trong mạng nội bộ. Các gói tin này được định địa chỉ để gán địa chỉ broadcast và multicast đặc biệt. Quảng bá được sử dụng nhiều trong các giao thức dựa trên UDP như là giao thức chia sẻ file SMB Microsoft Windows. Multicast được sử dụng chủ yếu trong các giao thức phân phát đa phương tiện như là RTP. TCP là giao thức điểm – điểm và không sử dụng gói tin broadcast hoặc multicast. uIP hỗ trợ các gói tin broadcast cũng như các gói tin multicast gửi đi.
b, Giao thức điều khiển bản tin Internet - ICMP
Giao thức ICMP được sử dụng để thông báo các điều kiện lỗi mềm và yêu cầu các thông số của các host. Tuy nhiên, sử dụng chính của nó là cơ chế phản hồi sử dụng
chương trình ping.
Hệ thống xử lý ICMP trong uIP rất đơn giản vì hạn chế chỉ thực hiện bản tin phản hồi ICMP. Phản hồi các bản tin phản hồi được tạo bằng cách tráo đổi đơn giản địa chỉ IP nguồn và đích của các yêu cầu phản hồi đến và ghi lại tiêu đề ICMP với loại bản tin Echo-Reply.
c, Giao thức điều khiển truyền – TCP
Thực hiện TCP trong uIP được điều khiển bởi các gói tin đến và các sự kiện định thời. Các gói đến được phân tích bởi TCP và nếu gói tin bao gồm dữ liệu để phân phát tới ứng dụng, ứng dụng được yêu cầu bằng phương pháp gọi hàm. Nếu gói đến xác nhận dữ liệu đã gửi trước đó, trạng thái kết nối được cập nhật và ứng dụng được thực hiện, cho phép gửi dữ liệu mới đi.
Lắng nghe kết nối
TCP cho phép một kết nối lắng nghe yêu cầu kết nối đến. Trong uIP, kết nối lắng nghe được xác định bằng số cổng 16 bit và các yêu cầu kết nối đến được kiểm tra so với danh sách các kết nối lắng nghe. Danh sách các kết nối lắng nghe này là tự động và có thể thay đổi bởi các ứng dụng trong hệ thống.
Khi gửi dữ liệu, một ứng dụng phải kiểm tra số byte sẵn có trong cửa số gửi và điều chỉnh số byte được gửi hợp lý. Kích thước cửa sổ gửi được qui định bởi cấu hình bộ nhớ cũng như không gian bộ đệm được thông báo bởi bộ nhận dữ liệu. Nếu không gian bộ đệm không có sẵn, ứng dụng phải hoãn và đợi gửi sau.
Không gian bộ đệm có sẵn khi một báo nhận từ bộ nhận dữ liệu được nhận. Bộ giao thức thông báo tới ứng dụng sự kiện này và sau đó ứng dụng lặp lại quá trình truyền dữ liệu.
Cửa sổ trượt
Hầu hết các hệ thống xử lý TCP đều sử dụng cơ chế cửa sổ trượt cho việc truyền dữ liệu. Nhiều segment dữ liệu được gửi theo chuỗi mà không cần đợi báo nhận cho mỗi segment.
Thuật toán cửa sổ trượt sử dụng rất nhiều hoạt động 32 bít bởi vì 32 bít là tốn kém trong hầu hết CPU 8 bít, uIP không thực hiện hoạt động này. Ngoài ra, uIP không lưu trữ các gói tin đã gửi đi và cơ chế cửa sổ trượt không lưu trữ các gói tin đã gửi sẽ phải được hỗ trợ bởi một lớp ứng dụng phức tạp. Thay vào đó, uIP cho phép chỉ một segment TCP đơn cho mỗi kết nối không được báo nhận tại bất kì thời gian xác định nào.
Ước lượng thời gian khứ hồi
TCP liên tục ước lượng thời gian khứ hồi (RTT) hiện thời của mỗi kết nối hoạt động để tìm một giá trị phù hợp cho thời gian chờ truyền lại.
Ước lượng RTT sử dụng bộ định thời tuần hoàn của TCP. Mỗi lần bộ định thời tuần hoàn khởi động, nó tăng giá trị bộ đếm cho mỗi kết nối không có báo nhận dữ liệu trong mạng. Khi một báo nhận được nhận, giá trị hiện tại của bộ đếm được sử dụng như một mẫu của RTT. Mẫu này được sử dụng cùng với hàm ước lượng RTT TCP tiêu chuẩn để tính toán một ước lượng RTT. Thuật toán của Karn được sử dụng để đảm bảo sự truyền lại không lệch sự ước lượng.
Truyền lại
Sự truyền lại được điều khiển bởi bộ định thời TCP tuần hoàn. Mỗi lần bộ định thời tuần hoàn được yêu cầu, bộ định thời truyền lại cho mỗi kết nối giảm đi. Nếu bộ định thời đạt giá trị 0, sự truyền lại được khởi động.
Vì không theo dõi nội dung gói tin sau khi chúng đã được gửi đi bởi driver thiết bị, uIP yêu cầu các ứng dụng dành một phần hoạt động cho việc truyền lại. Khi uIP quyết định một gói tin được truyền lại, nó yêu cầu ứng dụng với cờ báo rằng sự truyền lại được yêu cầu. Ứng dụng kiểm tra cờ truyền lại và tạo cùng dữ liệu đã được gửi trước đó. Các ứng dụng thực hiện việc truyền lại không khác so với dữ liệu gốc được truyền đi. Vì vậy,
các ứng dụng có thể được ghi theo cách mà các mã code được sử dụng cho cả việc truyền và truyền lại dữ liệu. Ngoài ra, cần chú ý rằng thậm chí hoạt động truyền lại thực tế được thực hiện bởi ứng dụng, đó là nhiệm vụ của bộ giao thức để biết khi nào cần truyền lại. Vì vậy, sự phức tạp của ứng dụng không cần thiết phải tăng lên bởi nó đã sử dụng một phần hoạt động cho việc truyền lại.
Điều khiển luồng
Mục đích cơ chế điều khiển luồng của TCP là để cho phép truyền thông giữa các host với kích thước bộ nhớ biến đổi nhiều. Trong mỗi segment TCP, bộ gửi của mỗi segment chỉ ra không gian bộ đệm sẵn có. Một bộ gửi TCP không gửi nhiều dữ liệu hơn không gian bộ đệm được báo bởi bộ nhận.
Trong uIP, ứng dụng, bộ gửi không thể gửi nhiều dữ liệu hơn dữ liệu host nhận có thể lưu trữ. Trước khi truyền dữ liệu, ứng dụng kiểm tra bao nhiêu byte được phép gửi đi và không gửi nhiều hơn dữ liệu mà các host khác có thể chấp nhận. Nếu một host ở xa không nhận được bất kì dữ liệu nào, bộ giao thức bắt đầu cơ chế thăm dò cửa sổ bằng không. (adsbygoogle = window.adsbygoogle || []).push({});
Điều khiển tắc nghẽn
Cơ chế điều khiển tắc nghẽn giới hạn số segment đồng thời trên mạng. Thuật toán sử