Messages posted by: Phineas

Chào bạn,

Ý của mình chỉ là tìm ra giải pháp trao đổi realtime dữ liệu 2 chiều hiệu quả trong 2 trường hợp trên. Trong trường hợp đầu, giao tiếp giữa chương trình thực thi và trang PHP có thể thực hiện qua tập tin.
Còn trong trường hợp còn lại, giao tiếp giữa webclient và webserver:

- Số lượng request từ client đúng là không nhiều khủng khiếp như bạn nói, nhưng do client không thể biết được lúc nào thì trên server sẽ được cập nhật nên request có chu kỳ khoảng vài giây (3-4s) một lần cho mỗi client. Chưa cần nói đến việc server hom hem hay không, đây rõ ràng là một cách không hiệu quả.
- Dùng PUSH như bạn nói là một giải pháp mình đang cần. Nhưng mình không biết liệu có cách nào thực hiện điều đó trong phạm vi web app thông thường không (hoặc thay đổi một chút ở phía webserver cũng được)? RAW socket hay embeded server chỉ là phương án cuối cùng thôi.

-
Cám ơn bạn.

Cám ơn bạn đã trả lời,

Thực ra do yêu câu của khách hàng, trang web mình viết có chức năng tương tự như meebo.com hay imo.im.
Hiện nay mình đang làm y chang như cách bạn nói, bên client dùng XMLHTTPObject bằng tay để cập nhận dữ liệu. Khổ nỗi, kiểu PULL này ngốn tài nguyên cả client lẫn server nhiều quá, do cứ định kỳ client lại request về server (y chang DoS), nên mình phải cần thêm khả năng PUSH từ phía server. <b>Không biết có thể giải quyết vấn đề này trong phạm vi web app php thông thường không nhỉ? Hay chỉnh lại config của Apache cũng được</b>

Cái RAW socket bạn nói là một dạng embedded webserver, mình mới google ra
www.koanlogic.com/klone/ cho phép nhúng C vào trong mã HTML (hay nhúng mã HTML vào C, :-D). Cái này có vẻ mới nên không chắc là có ổn định không nữa. Bạn nào xài rồi thì đánh giá dùm mình với.

Xài embedded server chỉ là cách cuối cùng, khi không còn cách nào khác để PUSH dữ liệu từ server một cách hiệu quả trong phạm vi <b>Apache - PHP/HTML - webclient</b> (1)

Bạn nào biết cách giải quyết vấn đề PUSH từ server này theo mô hình (1) trên thì chỉ cho mình với.

Cám ơn rất nhiều.

Mình bấm vào đó mà không thoát được trạng thái đăng nhập. Mình dùng Ubuntu 10.10, client Google Chrome.

Hiện nay mình đang dùng Ubuntu 10.10, webserver apache, có viết một trang PHP và cần gọi một chương trình thực thi (viết bằng C) qua trang PHP đó, cả 2 chương trình này cùng nằm trên 1 máy.
Chương trình cần gọi (A) có sử dụng một vòng lặp vô hạn của thư viện glib. Hơn nữa, mình cần trao đổi dữ liệu qua lại giữa chương trình cần gọi và PHP, cũng như giữa webserver và webclient theo realtime. Mình đã nghĩ tới 2 cách:
1. Gọi A thông qua webserver theo CGI (có dùng ajax)
2. Gọi A thông qua PHP và cho chạy background.

Lý do dùng ajax trong cách 1 hay chạy background trong cách 2 là do A có vòng lặp vô hạn, nếu gọi theo cách thông thường thì ở bên client, trang web sẽ bị treo.

Trong cả 2 cách để đảm bảo tính real-time, mình cho 2 chương trình trao đổi dữ liệu với nhau qua tập tin, rồi dùng PHP xử lý nội dung tập tin trả về cho client. Mình có một số thắc mắc, mong được các bác giải đáp:
1. Còn có cách nào hỗ trợ trao đổi thông tin real time cho 2 chương trình kiểu như trên để đạt performance cao hơn không? Nếu có, xin các bác chỉ giúp.
2. Có cách nào để duy trì luồng dữ liệu realtime giữa webserver và webclient không (ngoài cách cho webclient thực hiện request liên tục sau một khoảng thời gian nhất định)? Mong được các bác chỉ dùm.

Cám ơn rất nhiều.

Có một số cách sau:
1. Remote desktop tới máy tính ở nhà bật IM lên và chat bình thường.
2. Tự viết client chat (cái này recommend thư viện purple của pidgin) smilie

cài trên máy ở nhà, ssh vào rồi bật lên xài( cách này chắc ăn nhất).
Nói chung để đảm bảo 99% nội dung tin nhắn ko bị đọc được (vẫn bị sniff nhưng đã bị mã hoá), bạn cần kết nối tới một server ở bên ngoài, bảo nó chat rồi mã hoá thông tin gửi về máy bạn.

Theo tui thấy việc dùng XML thay cho cơ sở dữ liệu (CSDL) truyền thống như MySQL là khả thi (chưa xét đến khía cạnh security cho CSDL). Trong trường hợp CSDL nhỏ, bạn có thể đặt tất cả trong 1 file XML, trong trường hợp CSDL lớn, bạn có thể chia nhỏ ra nhiều file để đỡ ngốn tài nguyên, index chúng rồi quyết định dùng SAX hay DOM để giải quyết.

VD: đối với CSDL lưu thông tin đăng nhập của người dùng, bạn có thể chia thành từng tập tin XML nhỏ dựa theo thứ tự alpha beta của ký tự đầu của id của người dùng, rồi sau đó khi có yêu cầu login, dựa vào id đăng nhập do người dùng cung câp, bạn chỉ cần phải tìm thông tin trong file tương ứng mà bạn đã index và biết chắc chắn là id (nếu có) sẽ chỉ chứa trong file đó.

Việc dùng CSDL XML có một cái lợi cực kỳ quan trọng đó là khả năng phân tán và tập trung linh hoạt, do tính portable của file XML nên có thể dễ dàng chia nhỏ nó ra và đặt trên nhiều máy khác nhau, hoặc gom lại thành một file và đặt trên 1 máy. CSDL truyền thống cũng làm được điều này nhưng ko dễ dàng như là XML.

>>phanmemviet: Mình hiểu nhầm, đọc lại bài viết đầu tiên mình thấy là ko thể gửi thẳng xâu md5 đó lên cái app trên server (bởi vì cái app trên server sẽ md5 cái chuỗi md5 bạn gửi lên thêm một lần nữa) để qua mặt hệ thống kiểm tra được, tất nhiên trừ khi bạn can thiệp được vào server để thay đổi behaviour của cái app.
Trường hợp captcha thì lại khác, nếu bạn đã đọc được giá trị captchar bên client thì việc gửi lên để qua mặt cũng đơn giản thôi, cứ tuân thủ chặt chẽ theo RFC mà viết một client hoặc chịu khó google trên mạng. Mình nghĩ nếu bạn đủ khả năng phá captchar hay hack database để lấy md5 thì việc đó cũng ko khó khăn gì.

Edit: Về nguyên tắc, bạn muốn can thiệp vào một session đang xảy ra giữa server A và client B thì phải làm cho server "tưởng" bạn chính là B, vậy thì bạn phải có được thông tin mà server dùng để xác định B (như kiểu chứng minh nhân dân vậy) rồi gửi nó lên server trong lúc session đang xảy ra. Thông tin này thường là session ID, hoặc khắc nghiệt hơn, có thể là sự kết hợp thêm yếu tố khác, như IP chẳng hạn.

Ban đầu cứ gửi thẳng bằng một client hợp lệ mặc định (trong trường hợp này là browser) rồi sniff lại bằng wireshark, rồi bạn viết ra một cái client khác, copy theo cái mẫu lấy được trong wireshark, sửa lại một số trường theo ý bạn rồi gửi lên mà bug thử.