Messages posted by: hizit91

Mình xin đưa ra vài ý kiến:
1. Yêu cầu về cổng là yêu cầu của ứng dụng.

2. Còn việc xử lý cổng ở tầng giao vận
có giao thức dùng port ( UDP, TCP), giao thức không dùng port(ICMP),
xét với TCP:

Đối với gói tin đi : Một ứng dụng yêu cầu gởi thông tin : "Hello" tới địa chi <IP> : cổng <port>... thì <port> sẽ được thêm vào "TCP header", còn IP thì được thêm vào "IP header", hay nói cách khác <port> là do lớp TCP quản lý, và chính lớp TCP sẽ thêm thông tin <port> vào gói tin.
Đối với gói tin nhận: Khi một gói tin được nhận, gói tin nhận tới lớp TCP, lớp TCP sẽ quyết định, <port> này đang được "tiến trình" nào đang "lắng nghe", nó sẽ đưa dữ liệu tới "tiến trình" đó (tất nhiên là có sự tham gia của Session layer).

*_*.Những ý kiến trên mình viết ra là nhờ vào: "Xem gói tin ra, vào bằng Wireshare", hay nói rộng ra: "thực hành là yếu tố để ta củng cố, cũng như lấp đầy các thiếu sót lý thuyết"

qtra004 wrote:

Hizit91,

Em có xài Firewalls nào không, modem/router có Firewalls on không.

Em và bạn em thử tắt hết firewalls xem sao.

hí hí hí !!!!. anh chắc chắc là chưa "châm cứu" về networking rồi smilie

hehe

Mr.Khoai,

Mấy bữa ni dọn nhà, không được mẹ cho lên net smilie

, hôm nay 30 tết được lên mạng, vô hva thảo luận với anh cho vui smilie

,

Nhìn chung, mọi thứ có vẻ đã thông suốt, tuy vậy vẫn còn một trở ngại, em đã đưa interface của hamachi lên đầu tiên, khi dùng tinycar hay counter-strike thì gói tin broadcast có IP nguồn là 5.xxx.xxx.xxx, thì đúng rồi, nhưng IP đích là 255.255.255.255 ( địa chỉ limited broadcast ) chứ không phải là 5.255.255.255, như của windows SMB, do vậy mà em chẳng thấy máy thằng bạn, cùng một LAN trong hamachil, reply chi hết smilie

.., Rốt cuộc, kết quả vẫn là "không chơi được smilie

".....

Hizit91

anh qtra004 đưa tài liệu lên làm giảm bới tí thú vị smilie

hihihi.

Anh Khoai,
Tiếp tục trả lời các câu hỏi của anh KHOAI, thật ra em đã định trình bày luôn cái anh hỏi ở trên, nhưng để lại hai anh em cùng thảo luận từng bước cho hấp dẫn, trả lời luôn lần thì lấy gì mà nói tiếp smilie

.

Anh hỏi :

Nhưng, bạn vẫn chưa trả lời hết 3 trường hợp mà khoai nêu ra. Đúng là với destination IP là 5.123.123.123 hoặc 5.156.188.123 thì máy sẽ chọn Hamachi Interface. Vậy còn trường hợp A và trường hợp C thì sao?

.

=>Trả lời:
a, Với trường hợp A: gói tin có IP đích là 192.168.1.5, IP đích này được netmask 255.255.255.0 che phủ, tạo thành 192.168.1.0 trùng với "Network đích" ở dòng số 6 trong hình của em, nên nó được gởi qua Interface 192.68.1.3.

b. Với trường hợp C, cái này có ý nghĩa khi ta kết nối tới internet nè.
Giả dụ một kết nối tới internet bằng cách ping tới google.
Pinging google.com.vn [209.85.171.104],
Chuyện gì sẽ xảy ra, gói tin sẽ đi về đâu? Ban đầu ta sẽ hơi hoang mang về điều này vì IP 209.85.171.104 qua cảc netmask sẽ chẳng trùng với các Network đích thông thường được, thế ra ta không thể kết nối tới internet à?

Không phải vậy, hãy nhìn vào dòng đầu tiên của bảng "routing table"
Network Destination-------Netmask-------Gateway------ Interface------Metric
------0.0.0.0----------------0.0.0.0---------192.168.1.1---192.168.1.3-----20..

Một IP đích bất kỳ qua Netmask 0.0.0.0 thì chuyện gì sẽ xảy ra?, nó trở thành 0.0.0.0 và trùng với Network đich ở trên và như thế là gói tin tới google được chuyển tới Gateway 192.168.1.1 để đi tới internet smilie

.

Xong phần đầu, em tiếp tục giải quyết các câu tiếp theo, phần này lại thú vị nữa đây smilie

.
anh nói

Mở rộng thêm một chút, chú ý 3 dòng cuối cùng của routing table. Nếu mình send ra ngoài một gói broadcast với destination IP là 255.255.255.255 thì làm sao phân biệt interface nào mà send đi? Còn cái Metric trong routing table đó là cái gì? Được dùng đến khi nào?

Trước tiên em xin nói về Metric. Metric là "giá thành" của mạng, mạng có "giá thành" càng nhỏ(rẻ) thì càng được ưu tiên smilie

Một ví dụ rõ ràng hơn:
em thực hiện lệnh sau trong CMD : "route add 0.0.0.0 mask 0.0.0.0 5.156.188.57 metric 10"
kết quả là

Chuyện gì đã xảy ra, xuất hiện một routing mới cho Interface 5.156.188.57 với metric 10 < metric 20 của Interface 192.168.1.3, ở hai dòng đầu của bảng, do đó, một gói tin tới google bây giờ sẽ được gửi qua interface có "giá rẻ" hơn là 5.156.188.57, cho dù sẽ không có phản hồi smilie

, nhấn mạnh là gói tin sẽ không được gửi qua interface 192.168.1.3 vì có "giá" đắt hơn.
Với ba dòng cuối của bảng, vấn đề ở đây là gì? chúng có metric bằng nhau và đồng thời, khi gửi gói tin broadcast có địa chỉ đích 255.255.255.255 thì nó đều có khả năng qua cả ba interface, ở ba dòng cuối, vấn đề là, đây là vấn đề cốt lõi, là sao như game tinycar, couter-strike,... gởi gói tin broadcast với IP đích là 255.255.255.255 thì IP nguồn cho các INterface khác nhau đều giống nhau, và đều là IP nguồn của Interface có Order cao nhất trong thiết đặt Advanced->Advanced setting của Network connections như anh qtra004 đã từng nói, Tới đây, thì em sức cùng lực kiệt smilie

.
Anh đưa ra ý kiến đi smilie

.

hizit91.

Anh Khoai,

Thú vị quá!! Lâu rồi em mới có dịp thảo luận và "châm cứu" như thế này,-cùng với anh-.
Em xin phân tích các ý anh đã nêu với ý kiến của mình.
Anh đã nói:

"Nhưng khác nhau ở điểm bạn không cần làm vậy vì bạn chỉ cần sử dụng Hamachi để chơi game, còn interface kia không cần nhận gói broadcast đó. "

Quả thật, đâu phải em chỉ cần sử dụng "để chơi game", có nhiều ứng dụng cần tới broadcast, cho dù vậy, nếu " chỉ để chơi game" thì ta có thể áp dụng cronus, khi nào chơi thì ta bật nó, chơi xong thì tắt.

anh nói:

"Máy của bạn có một IP là 192.168.1.3/24, và một IP mà Hamachi sử dụng 5.156.188.157. Khi bạn send ra ngoài một gói tin đến các IP sau:

a. 192.168.1.5
b. 5.156.188.123
c. 1.2.3.4

thì chuyện gì xảy ra? Làm sao OS quyết định send ra interface nào? Và vì sao lại quyết định vậy?"

Cái này mới thú vị, em đã đọc được trong cuốn "TCP ...." ở tầng IP thì phải.....,
Để hiểu được đường đi của gói tin có IP đích bất kỳ, ta cần biết đến "routing table", tầng IP dùng bảng này để định hướng đường đi của gói tin tới interface được chỉ định. Trước tiên, Sử dụng lệnh "route print" từ CMD, ta nhận được kết quả là "routing table":

Nhìn vào bảng trên, ta phần nào hình dung được nguyên tắc hoạt động của nó:
Một gói tin IP đích bất kỳ, khi vào tầng IP , thì địa chỉ IP đích được che phủ lại bởi Netmask của từng dòng trong bảng trên, sau khi được che phủ thì địa chỉ IP của gói tin sẽ trở thành "Network Destination ", đem so sánh với giá trị "Network Destination " tương ứng trong bảng, nếu giống nhau, thì gói tin đó sẽ được gởi qua Interface trong cùng dòng đó.
Một ví dụ:
thực hiện lệnh sau trong CMD: "ping -t 5.123.123.123". Chuyện gì sẽ xảy ra?. Một quá trình vắn tắt sẽ là: một gói tin ICMP được tạo ra với IP đích là 5.123.123.123. Tới tầng IP, thì địa chỉ đích là 5.123.123.123 được che phủ bởi mask 255.0.0.0 ở dòng số 2 trong bảng?

Nhưng "che phủ " là gì?/Che phủ là một phép AND nhị phân( 1 and 1 =1, 0 and 1 = 0, 1 and 0 = 0, 0 and 0 = 0).
Như ta biết dãy 5.123.123.123 là dạng thập phân của một dãy 32 bit địa chỉ nhị phân.
5.123.123.123<=> 00000101 01111011 01111011 01111011 AND
255.00.00.00 <=> 11111111 00000000 00000000 00000000
kq: 5.00.00.00 <=>00000101 00000000 00000000 00000000
kq trùng với Network Destination trên dòng số 2 trong bảng, Do đó nó được gởi đi tới Interface 5.156.188.57.

**Ý cuối, "châm cứu" sơ sơ "routing table", trong đầu em định hình cho một cách khác, nhưng không biết vì sao lại không được, nếu anh đoán được ý em, anh có thể xem giúp em được không?

hizit91.

@qtra004: cảm ơn anh về các chỉ dẫn ở trên, nó đã phần nào giúp em nghiên cứu về vấn đề này, hihihi

qtra004 wrote:

Thật kì lạ vì anh đã sử dụng Hamachi cho cả game (WOW,Starcraft) và application (SQL Server) mà không có vấn đề gì cả. Em đã thử google xem người ta cài Hamachi cho game như thế nào chưa. Nếu như anh nhớ không lầm thì em có thể vào phần Advanced Settings của Network Connections rồi sắp xếp thứ tự Adapter cho Network services, Hamachi có 1 network adapter riêng, em thử sắp nó lên đầu xem sao

anh có thể nói rõ hơn được không?
Liệu các game kia có thể trực tiếp nhận ra game server trong cùng một LAN ảo do hamachi tạo ra hay ko? Tại em cũng chưa chơi các game đó smilie

, không biết là nó dùng broadcast để nhận biết game server hay là phải nhập trực tiếp IP của game server.

Mr.Khoai wrote:

hizit91 wrote:

Có lẽ cách viết của em khiến mọi người khó hiểu, em đã cố gắng cho nó đi theo trình tự thế này :
Đầu tiên, ta gặp một vấn đề trong thực tế, ở đây là việc "không chơi được các game multiplayer qua hamachi", từ vấn đề đó lại đặt ra nhũng câu hỏi( hay vấn đề) mang tính kĩ thuật (ở đây là vấn đề "Broadcasting tại host được kết nối tới nhiều Mạng"), em đã cố gắng trình bày cả một quá trình đi từ "game" --> "vấn đề kĩ thuật" của một học sinh 12 mới có những bước đi chập chửng vào "Nền tảng công nghệ về Mạng".
Cách thức tìm tòi này, theo em có thể mở rộng cho nhiều vấn đề khoa học khác, là cách thức đi từ một vấn đề thực tiễn, tới sự am tường, mở rộng những kiến thức nền tảng về vấn đề , sau cuối những kiến thức này lại cho ta nguồn "nội lực" để chinh phục những thách thức lớn hơn.

Chính xác! Từ những vấn đề thực tiễn hằng ngày ta có thể mở rộng ra nhiều hướng để học tập và nghiên cứu về IT nói chung một cách sâu sắc hơn.

heeee, em cũng đồng ý với anh về cái này smilie

Mr.Khoai wrote:

Không hẳn là vậy. Theo khoai được biết dịch vụ file sharing của Windows sử dụng multi-cast, không phải broadcast. Và, game bạn chơi không được chưa hẳn là do chuyện network của bạn có vấn đề. Cả hai dịch vụ (game và filesharing) đều sử dụng chung network stack của Windows, do đó có thể vì một lý do nào khác khiến cho game của bạn không chơi được (firewall, cấu hình game sai sót, vân vân).
khoai

Quả thật kiến thức là vô tận, tuy nhiên cái gì đã tìm hiểu thì phải hiểu rõ nó, nắm bắt được nó, và sự thật là em cũng chưa thật chắc về việc "filesharing của Windows" có dùng broadcast hay không, tuy vậy em cũng có lý do của mình để nói lên điều ấy. Trong thời gian "ngâm cứu" cái tinycar, thì hiển nhiên dịch vụ filesharing của Windows cũng đang chạy smilie

, và thế là một vài gói tin của nó "cũng phải" lột vào mắt em khi đang chăm chú nhìn các gói tin gửi đi của tiny car. Và thông điệp em bắt được từ các gói tin đó là:
(ảnh dưới đây được em minh họa lại tại phòng máy nhà trường chiều hôm nay)

như anh được thấy, nó được dùng bằng IP broadroad,rõ nhất là địa chỉ ở tầng Ethernet, đúng như em dự đoán smilie

tuy vậy, em cũng phải thắc mắc về câu này của anh "Theo khoai được biết dịch vụ file sharing của Windows sử dụng multi-cast", đành phải dời thời gian go home lại một tí, để ngâm cứu nốt, biết đâu cũng đúng thì sao :
Em bèn dùng google, kiếm một phen smilie

, quả thật khả năng tìm kiếm theo từ khóa của google không có cỗ máy tìm kiếm nào sánh bằng. Nó dắt em tới "wikipedia", lần mò trong mớ tiếng Anh xa lạ, em tìm được đoạn này

"Performance issues
Many people believe that the SMB protocol makes heavy use of network bandwidth because each client broadcasts its presence to the whole subnet. SMB itself does not use broadcasts. The broadcast problems commonly associated with SMB actually originate with the NetBIOS service location protocol. By default, a Microsoft Windows server will use NetBIOS to advertise and locate services. NetBIOS functions by broadcasting services available on a particular host at regular intervals. While this usually makes for an acceptable default in a network with fewer than 20 hosts, broadcast traffic will cause problems as the number of hosts increases. A proper implementation of a NetBIOS Name Server (NBNS) can mitigate this problem — for example Windows Internet Naming Service (WINS) offers a suitable solution in Microsoft environments. WINS uses a much more advanced system of registration and centralized service requests, but imposes its own complexity upon the design and maintenance of the network. Microsoft recommends the use of Dynamic DNS, another viable option, in Microsoft Active Directory environments.

Network designers should expect that latency will have a significant impact on the performance of the SMB protocol. Monitoring reveals this most commonly in cases of navigating among directories through SMB when significant network latency exists between hosts. For example, a VPN connection over the Internet will often introduce network latency, which can make for a frustrating experience."
Đoạn trên lấy từ link : http://en.wikipedia.org/wiki/Server_Message_Block

Anh có thể dịch thử xem sao?, gần tới giờ về rồi, em chỉ kịp thoáng qua và chú ý vào đoạn:

"SMB itself does not use broadcasts. The broadcast problems commonly associated with SMB actually originate with the NetBIOS service location protocol. By default, a Microsoft Windows server will use NetBIOS to advertise and locate services. NetBIOS functions by broadcasting services available on a particular host at regular intervals. While this usually makes for an acceptable default in a network with fewer than 20 hosts, broadcast traffic will cause problems as the number of hosts increases.".

Đoạn này có vẻ phù hợp với điều em nói, chỉ có khảc biệt là SMB dùng lớp NetBIOS, lớp NetBIOS lại dùng broadcasting, đó là giải pháp của Windows với mạng có dưới 20 host.

cả đoạn này của anh:

Mr.Khoai wrote:

"Khoai có đọc sơ sơ về RFC 947 mà bạn đề cập. Có vẻ như khái niệm Broadcast repeater hoàn toàn không thích hợp trong trường hợp này. Cái broadcast repeater mà RFC 947 đề cập là một thiết bị kết nối nhiều network/sub network với nhau, và chuyên relay các broadcast packets mà nó nhận được sang các network/sub network đó. "

Có lẽ anh đọc chưa kĩ cho lắm, hoặc là cũng có thể em đã dịch sai smilie

.
Em thấy trong RFC 947, nói về Cronus, thì cronus có một phần chức năng như em đã nói, phần chức năng còn lại như anh đã nói smilie

, hiii. Anh có thể dịch chi tiết RFC 947 dùm em, post lên đây để cả hai anh em cùng xem xét.

Lời bình cuối cùng, hiii, em gần về rồi, anh đã nói:

Mr.Khoai wrote:

"Và, game bạn chơi không được chưa hẳn là do chuyện network của bạn có vấn đề. Cả hai dịch vụ (game và filesharing) đều sử dụng chung network stack của Windows, do đó có thể vì một lý do nào khác khiến cho game của bạn không chơi được (firewall, cấu hình game sai sót, vân vân). ".

* EM xin khẳng định là vấn đề không phải do "network", "do game",vì em đã thử nhiều lần về cái network ở nhiều máy rồi, thứ hai là em cũng đã thử với Counter-stricke rồi smilie

, không được, nên không phải do game.

Xin được nhắc lại 1 câu trong loạt bài này:
"Nếu xem các tài liệu:"TCP/IP Illustrated", và "RFC 947" , các bạn sẽ thấy một điều thú vị, chính cái đó là nguyên nhân sinh ra loạt bài này của em."

Mr.Khoai wrote:

Đầu tiên phải nói là bạn cố gắng tìm tòi từ một vài điều khó hiểu ra cả chục điều không hiểu là chuyện rất đáng...vỗ tay tuyên dương trước bà con.
Nhưng mà khoai đọc đi đọc lại bài đầu (thay đổi vài chục lần) mà vẫn chưa hiểu ý bạn có gì thắc mắc và có gì không hiểu. Khoai nghĩ bạn nên làm quen cách diễn đạn đầy đủ, nhưng ngắn gọn, thay vì viết văn kể chuyện

Cảm ơn lời đánh giá của anh Mr.Khoai, có lẽ em sẽ phải từ bỏ lối viết văn kể chuyện đi smilie

và sự thật là em cũng không có năng khiếu về vấn đề này smilie

Có lẽ cách viết của em khiến mọi người khó hiểu, em đã cố gắng cho nó đi theo trình tự thế này :
Đầu tiên, ta gặp một vấn đề trong thực tế, ở đây là việc "không chơi được các game multiplayer qua hamachi", từ vấn đề đó lại đặt ra nhũng câu hỏi( hay vấn đề) mang tính kĩ thuật (ở đây là vấn đề "Broadcasting tại host được kết nối tới nhiều Mạng"), em đã cố gắng trình bày cả một quá trình đi từ "game" --> "vấn đề kĩ thuật" của một học sinh 12 mới có những bước đi chập chửng vào "Nền tảng công nghệ về Mạng".
Cách thức tìm tòi này, theo em có thể mở rộng cho nhiều vấn đề khoa học khác, là cách thức đi từ một vấn đề thực tiễn, tới sự am tường, mở rộng những kiến thức nền tảng về vấn đề , sau cuối những kiến thức này lại cho ta nguồn "nội lực" để chinh phục những thách thức lớn hơn.

Sau loạt bài viết này, em thừa nhận rằng mình mắc phải quá nhiều lỗi diễn đạt(bài viết đã được thay đổi nhiều lần nhưng vẫn còn mắc phải), cũng như lỗ hổng về kiến thức nền tảng, đó là biểu hiện sự non nớt của em. Tuy vậy, chính điều này lại là "Sự thể hiện chân thật nhất" về một cá nhân đang trên con đường tìm tòi những kiến thức mới, những vấn đề mới lạ.

Lại bàn về lời của anh Mr.khoai

Mr.Khoai wrote:

1. Game hay applications nói chung không quan tâm đến NIC hoặc card mạng là gì cả. Applications đơn giản chỉ yêu cầu gửi dữ liệu đến một IP hoặc một hostname nào đó. Chính OS sẽ lo việc truyền tải như thế nào. Hay cụ thể hơn, chính network sub system của OS sẽ lo vụ này.

Do đó, việc máy của bạn send broadcast ra interface với IP là 192.168.1.3 là do cấu hình của mạng, không phải do applications.

2. Để gửi dữ liệu ra tất cả các network interface, bạn cần thao tác trực tiếp với phần output của network sub system. Khi dữ liệu muốn được gửi ra ngoài, network sub system sẽ kiểm tra xem: Nên chọn source IP nào cho thích hợp, và với source IP đó thì device nào là thích hợp để gửi ra.
khoai

Em thừa nhận vấn đề (1) ở trên, theo như cách khai triển bài viết đã nói ở trên, đầu tiên điều này(1) chính là thắc mắc của em, qua quá trình "ngâm cứu" thì "cậu học sinh 12" đã biết được điều này và nêu lên "Đề xuất về cronus trong RFC 947" có liên quan tới ý (2) mà anh Mr.khoai nói.
Tuy vậy em cũng cần nhấn mạnh một ví dụ em đã nêu trong bài là " dịch vụ chia sẻ file của windows hay tổng quát hơn là tất cả hoạt động Workgroup đều suôn sẻ qua hamachi". Điều này nói lên rằng Windows đã áp dụng những thứ đại loại như Cronus để phục vụ cho Workgroup, từ đó em đã nêu lên đề xuất "Viết một lớp hỗ trợ cho Windows, một thứ tương tự như Cronus, để áp dụng được cho tất cả các ứng dụng."

Anh Mr.khoai đã nói:

"bạn cần thao tác trực tiếp với phần output của network sub system", "network sub system sẽ kiểm tra xem: Nên chọn source IP nào cho thích hợp, và với source IP đó thì device nào là thích hợp để gửi ra".

Nếu xem các tài liệu:"TCP/IP Illustrated", và "RFC 947" , các bạn sẽ thấy một điều thú vị, chính cái đó là nguyên nhân sinh ra loạt bài này của em smilie

.

đã gộp lên bài đầu !!!

K4i wrote:

viết thế này thì có ma hiểu thôi em ơi , mà ai bảo em đọc TCP/IP Illustrated làm chi, ngồi tìm mấy quyển tiếng việt mà đọc trước đã em ạ .

dạ anh! em cũng đọc "qua" smilie

mấy cuốn tiếng việt rồi anh à! rất sơ sài!
Theo em nghĩ mấy cuốn này mà dành cho ai chỉ đọc qua "cho biết" thì ok! Nhưng em lại đang muốn giải quyết một vấn đề phát sinh! từ đó lại đặt ra cần phải nắm vững hệ thống. Lấy cái "Bất biến mà ứng vạn biến" hiii, hay là theo em nghĩ, đã học cái gì thì không nên mơ hồ, biết qua, mà mình cần nắm cái nền tảng, cái cơ sở, từ đó mà kiến thức được triển khai một cách xuôn sẻ giúp cho không chỉ một mà nhiều vấn đề được giải quyết.

Qua những lập luân trên nên em quyết định đọc cuốn "TCP/IP Illustrated ", không quá nâng cao, áp dụng lý thuyết kèm bài tập, ví dụ thực hành, nhìn chung là rất hay hiii, cũng bởi tại vì thế mà dù xuất bản từ rất lấu, công nghệ ngày càng hiện đại, nó vẫn giữa được vị trí của mình ( mà dù sao cốt lõi của Mạng vẫn không hề thay đổi tới ngày nay)!!! hiii

*note thêm: "viết thế này thì có ma hiểu thôi em ơi smilie

", có lẽ phải xem lại cách diễn đạt ý kiến của mình, thanks anh!

đã gộp vào thành 1 bài !!!

có lẽ ko ai giải quyết vấn đề này cho mình cả smilie

,
ok!!!!
em đang đọc :"Addison-Wesley-tcpip-illustrated"--> vận công hết sức vốn tiếng anh( sau 6 năm rữa vật lộn với số 6,5) để dịch smilie

để giải quyết những vấn đề cho hôm nay và mai sau, hiii.

Kiểm tra HK I, cả trường được vừa học vừa chơi một tuần trước khi qua HK II, thế là em cùng mấy đứa bạn trong lớp rủ nhau cùng chơi các game multiplayer. Đứa nào cũng ý định: "chắc là dùng Hamachi để tạo VPN là ok thôi"... Hăm hở vào...cài... mọi thứ dường như đã ổn,.... cả bọn đã có thể share file với nhau qua workgroup của windows. . Tụi em cài thử 1 cái game để xem thế nào. Game được đưa ra thử nghiệm là :"Tinycar" smilie

, một trò khá nhỏ, nếu chơi cở 4 người với nhau thì ok smilie

. nó đã có sẵn multiplay rồi. chừ 1 đứa ( em nhận trách nhiệm này) vô tạo server.

Tạo xong, thằng nào cũng vô rồi mà refresh server lại chẳng thấy cái server của em. tụi bạn hết nhẫn nại rũ nhau đi chơi Fifa online, còn em thì vẫn loay hoay để thỏa chí tò mò! vả lại đọc 2 cái ký sự của anh(bác) conmale cũng thấy thích, nghĩ rằng cũng không quá phức tạp đối với một học sinh 12 smilie

Dùng cái Wireshark "túm" cái gói tin xem như thế nào ( thừa nhận em cũng đọc qua về cái TCP/IP rồi nên mới tò mò thực hành). Em nhận thấy tinycar liên tục phát những gói tin như hình (em bắt gói tin ở phần cứng mạng của hamachi )

Em nhặt nhạnh các thông tin từ wireshark :

1.Đích là broadcast ( như hình ), cái này để máy tụi bạn em đều nhận ra, là đúng rồi smilie

....

2. Nhưng smilie

:
a. IP đích là 255.255.255.255 trong khi subnet mask của hamachi là 255.0.0.0 và IP của em là 5.xxx.xxx.xxx
tức là IP đích theo logic phải là 5.255.255.255.
b. như đã nói trên IP theo hamachi đặt cho em là 5.xxx.xxx.xxx nhưng khi gói tin send đi lại có IP là 192.168.1.3 là IP mạng LAN do modem router của em đặt.

Một thử nghiệm khác được đưa ra : em tắt đi phần cứng mạng thật( có địa chỉ IP 192.168.1.3) và phần cứng mạng ảo của hamachi vẫn còn bật.

bây giờ thì IP nguồn lại là 5.xxx.xxx.xxx. Vậy là sao? Quả thật trong đầu em lúc này xuất hiện nhiều câu hỏi:
a. Chắc là game này chỉ nhận ra được 1 phần cứng mạng à?--> nhưng cái đó là do hệ điều hành quản lý, không biết có liên quan tới game không?
b. Nhưng mà làm sao nó có thể send qua cả phần cứng mạng thật(đã được thử) và phần cứng ảo của hamachi được kìa? chẳng lẽ nó "cũng có biết" hamachi smilie

c. vậy có phải là nó nhận ra cả hai nhưng lại send đi với gói tin giống nhau?, đều là như cho cái 192.168.1.3.

*** Quá nhiều câu hỏi đặt ra, em đành tạm gác "mớ" "bòng bong" sang một bên, quyết định ra quán chơi với tụi bạn smilie

. heeee

Xin sự trợ giúp của các anh(các bác), các chị( các cô) ? smilie

Ghi chú:
Trong bài viết tác giả có dùng tới 2 tên gọi:"Phần cứng mạng thật", và "Phần cứng mạng ảo của hamachi".
Vì lý do chưa nắm hết định nghĩa, nói cách khác là chỉ hiểu theo cách trực quan, của tác giả tại lúc viết bài này nên mong mọi người chấp nhận cùng tác giả rằng:
a. "phần cứng mạng thật": một mạng có card mạng gắn trên mainboard hẵn hoi, và được dùng để kết nối tới Internet.
b. "Phần cứng mạng ảo của hamachi": một VPN( mạng riêng ảo) được hamachi tạo ra.

====================================================
=========
Một ngày học hành cũng trôi qua! Tối nay rãnh lại tiếp tục đem ra ngâm cứu vấn đề bữa trước:
==========

Nhân lúc rãnh em đem cuốn "Addison-Wesley-tcpip-illustrated" ra đọc! Vận công một lúc, may mắn tìm thấy đoạn này:

"Broadcasting và Multicasting.

12.1 Introduction

We mentioned in Chapter 1 that there are three kinds of IP addresses: unicast, broadcast, and multicast. In this chapter we discuss broadcasting and multicasting in more detail.

Broadcasting and multicasting only apply to UDP, where it makes sense for an application to send a single message to multiple recipients. TCP is a connection-oriented protocol that implies a connection between two hosts (specified by IP addresses) and one process on each host (specified by port numbers).

Consider a set of hosts on a shared network such as an Ethernet. Each Ethernet frame contains the source and destination Ethernet addresses (48-bit values). Normally each Ethernet frame is destined for a single host. The destination address specifies a single interface-called a unicast. In this way communication between any two hosts doesn’t bother any of the remaining hosts on the cable (except for possible contention for the shared media).

There are times, however, when a host wants to send a frame to every other host on the cable-called a broadcast. We saw this with ARP and RARP. Multicasting fits between unicasting and broadcasting: the frame should be delivered to a set of hosts that belong to a multicast group.

To understand broadcasting and multicasting we need to understand that filtering takes place on each host, each time a frame passes by on the cable. Figure 12.1 shows a picture of this.

First, the interface card sees every frame that passes by on the cable and makes a decision whether to receive the frame and deliver it to the device driver. Normally the interface card receives only those frames whose destination address is either the hardware address of the interface or the broadcast address. Additionally, most interfaces can be placed into a promiscuous mode whereby they receive a copy of every frame. This mode is used by tcpdump, for example. "
====
xin được phỏng dịch:
===========
"Broadcasting và Multicasting.

12.1 Giới thiệu:

Như chúng tôi đã giới thiệu ở phần 1 thì có 3 loại địa chỉ IP: unicast, broadcast, và multicast. Trong phần này tôi sẽ nói rõ về broadcasting và multicasting.

Broadcasting và multicasting chỉ áp dụng được với UDP, có nghĩa là, mỗi ứng dụng một lần gởi đi một thông tin riêng lẽ tới nhiều người nhận. TCP thì lại là giao thức có định hướng, do đó chỉ có thể là kết nối giữa 2 host và một tiến trình cho mỗi host ( được đặc trưng bằng cổng -port number - ).

Xét một tập hợp nhiều host trên mạng chia sẻ, chẳng hạn Ethernet. Thông thường mỗi Ethernet frame -1- có đich tới chỉ là một host duy nhất, và địa chỉ đích tới lúc này thuộc loại unicast.

Đó là trường hợp thường, trong trường hợp một host muốn gởi một frame tới tất cả các host nằm trên cùng một tuyến cable. Khi đó địa chỉ đích thuộc loại Broadcasting. Còn với Multicasting thì nó nằm giữa Broadcasting và unicast, tức là frame gởi đi sẽ chỉ được các máy thuộc nhóm multicast tiếp nhận.

Để hiểu được broadcasting và multicasting, ta cần, xem một frame trên cable được chọn lọc là tiếp nhận( hay loại bỏ đi) như thế nào?

Đầu tiên,ở chế độ thông thường, card mạng -2- phần cứng mạng) sẽ chỉ tiếp nhận các frame trên cable có địa chỉ đích
là chỉ tới nó, hay địa chỉ đích thuộc loại Broadcasting.

Tuy vậy vẫn có 1 chế độ "không phân loại" ( promiscuous mode) của card mạng cho phép tiếp nhận tất cả frame
được gởi trên cable, chế độ này được dùng trong các phần mềm bắt gói tin, như tcpdum là một ví dụ."
===
-1- : một dãy các tín hiệu được truyền lên cable cùng nằm trên một đơn vị dữ liệu của lớp ethernet.
-2- : phỏng dịch.
=======

và cả đoạn này nữa:

"Limited Broadcast

The limited broadcast address is 255.255.255.255. This can be used as the destination address of an IP
datagram during the host configuration process, when the host might not know its subnet mask or even
its IP address.

A datagram destined for the limited broadcast address is never forwarded by a router under any
circumstance. It only appears on the local cable.

An unanswered question is: if a host is multihomed and a process sends a datagram to the limited
broadcast address, should the datagram be sent out each connected interface that supports
broadcasting? If not, an application that wants to broadcast out all interfaces must determine all the
interfaces on the host that support broadcasting, and send a copy out each interface. "
====
Thấy hay hay, bèn dịch ra xem thử:
=======
"Limited Broadcast -1-.

Địa chỉ Limited broadcast là 255.255.255.255. Địa chỉ này có thể được dùng làm địa chỉ đích đến của một IP datagram-2- trong thời gian tiến trình thiết đặt host được thực thi, khi một host không biết subnet mask hay địa chỉ IP của chính nó.

Một datagram với địa chỉ đích là Limit broadcast thì không bao giờ được chuyển tiếp bởi bất kỳ router nào trong bất kì hoàn cảnh nào. Nó chỉ xuất hiện trên cable cục bộ.

Một câu hỏi không trả lời được là : Nếu một máy có nhiều card mạng -3- và một tiến trình gởi đi 1 gói tin với địa chỉ limited broadcast, có thể gói tin sẽ được gởi đi qua mỗi card mạng hỗ trợ broadcasting.? Còn không, một ứng dụng nếu muốn broadcast tới tất cả card mạng sẽ phải xác định rõ ràng tất cả các card mạng trên máy, những cái nào hỗ trợ broadcasting, rồi sau đó gởi tới từng card mạng riêng biệt"
==
-1- : Xin được để nguyên không dịch. hiii
-2- : gói tin được tầng IP gởi tới lớp dưới trong mô hình mạng ( đã cụ thể là dùng giao thức IP).
-3- : Mạn phép được dịch "connected interface" là "card mạng". Dịch nguyên văn thì là "giao diện kết nối".
=====
** lưu ý hai đoạn trên được dịch có nội dung không hoàn toàn đúng với nguyên bản tiếng anh của nó, tác giả chỉ dịch nhằm lấy thông tin phục vụ bài viết!

***Vậy liệu có phải các game( đã thử với CS) đã dùng cùng một gói tin có địa chỉ đích broadcast từ đó gói tin đó được gởi cho tất cả các card mạng, chứ không phải như dịch vụ "chia sẻ file" của windows trong LAN, nó gởi gói tin broadcast riêng biệt cho từng card mạng, với ( IP và subnet đã biết) do đó có thể chia sẻ file mà không cần biết chính xác IP các máy đích.

=================================================

=======
Lại một ngày học ( 1 sinh, 2 Lý, 2 tin ) đầy mệt nhọc nhưng không kém phần thú vị trôi qua. Thời gian rãnh tối nay mình dành thời gian chỉnh sửa lại các bài viết( gộp lại thành 1, lược đi các phần không quan trọng, thêm tí màu mè vô). Mong mọi người bỏ qua vì sự chỉnh sủa này.
Em quyết định "ngâm" nốt vấn đề đặt ra:
============

Tiếp tục tìm lời giải cho những tò mò của mình, từ việc gặp trở ngại khi chơi những game multiplayer trong LAN qua quá trình tìm tòi, em nhận thấy nó chỉ là phần nổi của một vấn đề lớn hơn, đó là vấn đề "Broadcasting tại host được kết nối tới nhiều Mạng".

Ai đó có thể đã từng đọc, hay sẽ đọc tài liệu "RFC 947", thì sẽ biết phần nào đó về vấn đề mà em đang nói ở trên, thật lòng, thời gian và cả khả năng hiện thời cũng không cho phép em nắm hết về vấn đề này.

Em cũng chỉ nêu lên một cách sơ bộ một phương án được nhắc đến trong "RFC 947".
Đó là Cronus, nhiệm vụ của nó là nhận xử lý các yêu cầu Broadcast tới toàn bộ các mạng được kết nối, từ đó dựa vào Network ID và Subnet mask mà gởi đi gói tin broadcast với địa chỉ IP nguồn tương ứng với từng mạng riêng biệt được kết nối tới.

Một ví dụ:
Ta có hai mạng được kết nối tới là:
1. 192.168.1. với subnet mask là 255.255.255.0, IP hiện tại của host là 192.168.1.5.
và
2. 10.4.0. với subnet mask là 255.255.255.0, IP hiện tại của host là : 10.4.0.20.

Xét một yêu cầu broadcast tới tất cả các mạng được kết nối, sẽ được chia thành hai gói tin khác nhau gởi tới 2 mạng khác nhau đó (lưu ý cả hai gói tin đều là gói tin broadcast nên địa chỉ MAC đều sẽ là FF-FF-FF-FF-FF-FF)
1. gói tin đầu : được gởi cho mạng 192.168.1 với IP nguồn là 192.168.1.5. và IP đích là 192.168.1.255.

2. gói tin thứ hai: được gởi cho mạng 10.4.0 với IP nguồn là 10.4.0.20. IP đích là 10.4.0.255.

Nhìn lược qua, ta có thể đưa ra ý kiến rằng, cronus là không cần thiết, mỗi ứng dụng sẽ tự làm điều đó, nhưng ngặt nỗi đa phần các ứng dụng không quan tâm tới điều trên ( các trò chơi qua LAN như tiny car, counter-stricke, hay đa phần các game khác...) ngoại trừ như giao thức SMB của Windows chẳng hạn, dường như, theo các gói tin em bắt được ở các giao tiếp mạng khác nhau ( qua hamachi, và cả OpenVPN...), thì nó dùng gói tin broadcast có địa chỉ nguồn khác nhau cho từng mạng riêng biệt, đó cũng là lí do mà dịch vụ chia sẻ file, như em đã nói, nó hoạt động thông suốt qua hamachi, và em đoán chắc rằng điều này cũng hoàn toàn đúng khi dùng openVPN để tạo VPN.

Vậy, đề xuất đặt ra Cronus là rất hữu ích (hình như nó đã được áp dụng trên nền Unix từ lâu để đơn giản hóa các bước ở lớp trên, cũng như các việc mở rộng khác...). Nhưng trên Windows thì sao?, dựa vào tình hình được phân tích như trên thì hình như cronus, hay những thứ đại loại như cronus chưa được áp dụng trong Windows.

Vậy! phải chăng ta có thể viết một lớp bổ sung cho Windows tương tự như cronus?