Cuộc họp các nhà phát triển I2P - 16 tháng 5 năm 2006

<cervantes> moo: http://dev.i2p.net/pipermail/i2p/2006-May/001289.html <cervantes> 0) chào <cervantes> 1) jrandom không có ở đây <cervantes> 2) ??? <cervantes> 0) chào <cervantes> chào <cervantes> chuyển sang 1) <cervantes> hôm nay jrandom không có ở đây, nhưng ngày mai anh ấy sẽ cập nhật tình hình cho chúng ta <cervantes> 2) ??? <cervantes> có ai còn gì để bổ sung cho buổi họp không? <bar> tôi có một câu hỏi <cervantes> vậy thì... * cervantes lấy đà * cervantes ngừng lấy đà <Complication> Aha, một câu hỏi... <bar> bản vá PRNG (bộ sinh số ngẫu nhiên giả) trong cvs, liệu nó có cải thiện hiệu năng tổng thể hay liên quan đến thứ khác? <cervantes> chưa chắc nó sẽ có những hệ quả gì nói chung <Complication> Cá nhân tôi không nắm được toàn bộ tác động của nó, nhưng nó liên quan ít nhất đến hai hành vi tôi biết: <cervantes> nhưng nó cụ thể sửa một triệu chứng với i2ptunnel * cervantes để Complication giải rối <Complication> ngẫu nhiên hóa độ dài tunnel và lựa chọn máy chủ IRC (khái quát hơn, chọn ngẫu nhiên từ một danh sách đích I2PTunnel) <Complication> Việc ngẫu nhiên hóa độ dài tunnel có lẽ có ảnh hưởng đáng kể đến sức khỏe chung của mạng, vì nó cho phép các client được phép thỏa hiệp về độ dài tunnel thực sự làm điều đó <Complication> Vì thế họ sẽ không cứ nín thở mà chỉ dựng tunnel 2-hop, mà còn thử cả một số tunnel 1-hop <Complication> (mà vào lúc khó khăn thì dễ đạt được hơn nhiều) <cervantes> cũng có thể kết nối IRC được cải thiện khi nó được triển khai. Về cơ bản freshcoffee chẳng bao giờ nhận được kết nối client vì nó đứng thứ hai trong danh sách - nên với bản phát hành tới, tải sẽ được phân phối đều giữa cả hai máy chủ <bar> vậy lỗi đó khiến mọi người luôn chọn độ dài tunnel dài hơn nếu có sẵn? <Complication> Nếu tôi hiểu đúng, mọi phép ngẫu nhiên với số nguyên nhỏ (vd: chọn 0 hoặc 1) đều bị ảnh hưởng <Complication> Tôi nghĩ là các phép ngẫu nhiên với số nguyên lớn hơn (vd: chọn một số nguyên giữa 0 và 100) bị ảnh hưởng ít hơn <Complication> nếu bạn quan tâm, có lẽ bạn nên hỏi jranom để biết chi tiết khi anh ấy quay lại <Complication> Tôi có thể nhầm chi tiết. <bar> tôi hiểu rồi, cảm ơn. bắt lỗi tốt đấy <Complication> ừ thì, cervantes đến đây và bắt đầu than phiền vì chẳng bị quá tải chút nào ;P <cervantes> tôi cũng hiểu như vậy <cervantes> thấy không... trong đời mà không càm ràm thì chẳng được gì đâu :) <cervantes> mọi người còn câu hỏi hay chủ đề nào khác cho buổi họp không? <fox> <duck> có <Pi> một câu hỏi về sức khỏe mạng nói chung: tôi thấy ngày càng nhiều client bị tụt lại về phiên bản I2P (2 cái vẫn dùng 0.6.1.11, v.v.). những client này có khiến việc theo dõi tác động của các thay đổi lên core ngày càng khó hơn không? (vì có vẻ "ít" người muốn cập nhật) <fox> * duck lặp lại ở trên * w423412323 đề xuất đổi chủ đề theo hướng đó. ;) <fox> <duck> Tôi tự hỏi, tôi đã thấy một số commit tinh chỉnh kỳ lạ trên mailing list cvs. đó là thêm các thử nghiệm? dựa trên quan sát? hay hơi sớm? <Complication> Pi: miễn là chúng không xuất hiện với số lượng lớn, chúng sẽ không tạo khác biệt nhiều <Pi> 70 trong 300 client đang dùng phiên bản khác 0.6.1.18 theo netdb của tôi bây giờ <Complication> Đó là trò chơi của con số và năng lực - nếu hoặc là đa số router, hoặc thêm vào đó các router có năng lực cao nhất được cập nhật ở mức hợp lý, thì việc một số người quên rằng họ đã cài I2P cũng không sao :) <cervantes> Pi: nếu các router cũ cư xử không đúng thì mạng _nên_ thích nghi và giảm lượng traffic được router qua chúng <cervantes> *được định tuyến <cervantes> Complication: bạn có thấy câu hỏi của duck không? <Pi> và một câu hỏi về một thống kê trên i2p-console xuất hiện cách đây một thời gian: handle backlog nghĩa là gì? <Complication> duck: bạn muốn nói đến các điều chỉnh throttle của tunnel? Chúng là tinh chỉnh theo nghĩa là chúng không mang lại nhiều thứ hoàn toàn mới, nhưng giờ chúng đã được thử nghiệm khá kỹ (vd: có lẽ chúng sẽ không 'cắn' (byte)) <Complication> Nhưng chúng có thể 'cắn' một chút, nếu bạn chạy một cấu hình lập dị hoàn toàn ngoài các tham số tôi có thể nghĩ tới <fox> <duck> Complication: tôi tự hỏi liệu mấy thứ '2' thay vì '3' có thực sự quan trọng đến thế không <fox> <duck> nhưng có vẻ vấn đề random có thể đã là một thứ tệ hại lớn <fox> <duck> (mặc dù mức tác động tương đối của nó tới tình trạng mạng kém khỏe còn phụ thuộc vào thời điểm nó được đưa vào) <cervantes> Pi: handle backlog là số lượng yêu cầu tham gia tunnel đến đang chờ xử lý (trích từ changelog) <Complication> Nếu bạn nói tới vấn đề random nextInteger() và tác động lên việc ngẫu nhiên hóa độ dài tunnel, tôi cảm thấy nó sẽ có ảnh hưởng đáng kể <Complication> Chênh lệch chi phí giữa việc dựng tunnel 1-hop và 2-hop là khá đáng kể <Pi> cảm ơn, cervantes :) <fox> <duck> nó được đưa vào khi nào? <Complication> duck: tôi nghĩ nó được đưa vào cùng với một số chuyển đổi sang Fortuna generator, hoặc một số chỉnh sửa trong đó <fox> <duck> ok; cảm ơn bạn rất nhiều vì phần chia sẻ <Complication> Để tôi kiểm tra cvsweb để có thêm chi tiết... <cervantes> Pi: tôi tin rằng giờ đã có mã đặt vào để bỏ bớt các yêu cầu tunnel đến nếu hàng đợi đầy (để giúp giảm tải CPU) <Complication> Pi: vâng, đó nên là chỉ báo có thể thấy của một tham số khác dùng để quyết định "chúng ta có đủ năng lực để tham gia thêm một tunnel nữa không?" <cervantes> duck: tôi chắc chắn thấy một thay đổi lớn trong hành vi của router kể từ khi bản vá được đưa vào. - không phải tất cả đều tốt, phải nói vậy :) <Complication> big handle backlog == tắc nghẽn, không có lý do gì để cố tham gia tunnel của người khác <cervantes> hôm nọ có load average 14 và 12000 tunnel tham gia <Complication> Handle backlog có vẻ quan trọng đặc biệt trên các router dung lượng cao (ám chỉ những gì cervantes thấy) <Complication> Các router dung lượng thấp thường điều tiết việc chấp nhận tunnel vì lý do băng thông <Complication> (hoặc lý do thời gian kiểm tra tunnel, cho chính xác) <Complication> (hoặc ít nhất, cố gắng như vậy) <cervantes> ồ chúng ta đã kéo được nửa giờ rồi.... <Complication> Đúng vậy :D <cervantes> ai muốn đưa thêm điều gì lên bàn không? <cervantes> vậy thì... * cervantes lấy đà * cervantes *baf* tuyên bố kết thúc buổi họp <fox> <duck> cảm ơn vì đã lo liệu buổi họp <cervantes> heh tôi đã định 'baf' nó đóng lại trước khi ai nói gì....nhưng bar đã phá hỏng kế hoạch đó :)