Chào mọi người, mình đang thiết kế hệ thống chat có chức năng hiển thị trang thái tin nhắn: Đã gửi(sent), Đã giao(delivered) và Đã đọc (Read). Nhưng mình đang bí làm thế nào để tracking tin nhắn đó. Hiện tại thì khi tin nhắn được gửi tới server, tin nhắn sẽ được lưu vào database với id. Tuy nhiên khi người gửi gửi tới server thì tin nhắn đó chưa được tạo nên server có gửi lại cho người gửi để thông báo tin nhắn đã được gửi thì người gửi cũng không biết đó là tin nhắn nào. Mình đang nghĩ tới hay là khi client gửi tin nhắn thì tin nhắn đó phải kèm id để nhận dang. Tóm lại là id tin nhắn phải được tạo khi client gửi tin nhắn chứ không phải được tạo ở server. Cảm ơn ạ.
Tracking tin nhắn (message) trong hệ thống chat
vậy thì làm như bạn nói đi, gen thêm một cái id để gửi kèm theo tin nhắn để phục vụ có việc định danh và cập nhật trang thái tin nhắn
có vấn đề gì?
2 Likes
Mình phân vân là có cách nào khác không. Nếu làm vậy thì 1 mesage sẽ có 2 id…1 id ở client, 1 id ở server
đâu có lý do gì để phải lưu 2 id
có nhiều giải pháp cho chuyện này
client gen id tạp để định danh, sau khi server nhận được message và id tạm đó, lưu message + id gen bới server, thì emit lại event nói cho client biết là cái message vừa gửi đi lúc nãy có id thật sự là gì, client thay id tạm bằng id thật sự
hoặc server dùng id của client gen ra làm id luôn
4 Likes
Định danh chung do máy chủ tạo ra chứ bạn, nhưng vấn đề là tin từ máy gửi đến máy chủ?
Tạo 1 định danh tạm giữa máy chủ và máy gửi (sẽ hủy sau khi xác nhận “Sent”) hoặc gửi yêu cầu tạo định danh trước khi gửi tin nhắn.
4 Likes
Mình nghĩ cách tạo id tạm của bạn sẽ hợp lý hơn. Còn server thì không nên lưu id do client tạo ra…
Bạn có cho chat nặc danh không cần biết user hay không? Nếu cho, câu này “Tuy nhiên khi người gửi gửi tới server thì tin nhắn đó chưa được tạo nên server có gửi lại cho người gửi để thông báo tin nhắn đã được gửi thì người gửi cũng không biết đó là tin nhắn nào.” là có thể hiểu được. Nhưng, nếu người chat là user có đăng ký, bạn phải kiểm tra xem đó là ai để phân phát đến người nhận, và một phiên chat là có 2 user để phân phát tin nhắn đến đúng người => nhận định của bạn vừa nói đã không còn có lý.
Bạn căn cứ vào gì để nói như vậy? Thế nào là không nên? Cái vấn đề ở đây là bạn thiết kế cơ sở dữ liệu, và cái khoá token hoặc ID để bạn phân biệt tin nhắn nào với tin nhắn nào thì bạn có thể tạo ra bằng nhiều cách, có thể sẽ kết hợp giữa client, đồng hồ hệ thống và cái gì đó ở server. Hơn nữa, hệ thống chat của bạn đang nói là đang dựa trên client - server, nhưng ngày nay người ta còn có hệ thống khác là client - client, và dùng server chỉ là tracker mà không lưu trữ tin nhắn trên server, cái này mà không sử dụng đến client thì mình nói thật là chưa biết làm sao.
2 Likes
Hệ thống của mình không những không cho chat nặc danh mà xác thực người còn khá gắt ghe. Không cho phép đăng ký user mà user chỉ được tạo bởi một admin duy nhất do tính chất hệ thống. Tất cả request gửi lên server đều phải kèm access token để định danh user.
Có thể nhận dạng được tin nhắn đó trong cuộc hội thoại giữa người nào với người nào. Nhưng ví dụ người A gửi cho người B một lúc 3 tin nhắn. Server báo cho người A rằng tin nhắn 1 đã được gửi thì người A làm thế nào để biết đó là tin nhắn 1 chứ không phải là tin nhắn 2 hay 3?
Một trong những lý do của mình đó là server sẽ là nơi tạo tin nhắn để lưu vào database, id tin nhắn được tạo theo tuần tự để khi lấy chat history có thể sắp xếp được (không dùng được thời gian tạo tin nhắn để sắp xếp vì 2 tin nhắn có thể có cùng thời gian tạo). Rồi nếu id được tạo ở client thì có nguy cơ trùng lặp (không tính tới UUID hay GUID).
Cái này có thể apply cái cớ chế message request-reply + Correlation Identifier.
There are six parts to Correlation Identifier:
1. Requestor — An application that performs a business task by sending a request and
waiting for a reply.
2. Replier — Another application that receives the request, fulfills it, then sends the reply. It
gets the request ID from the request and stores it as the correlation ID in the reply.
3. Request — A Message sent from the requestor to the replier containing a request ID.
4. Reply — A Message sent from the replier to the requestor containing a correlation ID.
5. Request ID — A token in the request that uniquely identifies the request.
6. Correlation ID — A token in the reply that has the same value as the request ID in the
request.
Tìm đọc cuốn Gregor Hohpe, Bobby Woolf - Enterprise Integration Patterns_ Designing, Building, and Deploying Messaging Solutions -Addison-Wesley Professional (2003) phần Message Construction
3 Likes
mình đó là server sẽ là nơi tạo tin nhắn để lưu vào database,
Thế thì bạn đang lập trình chatbot hay sao? Người dùng tạo ra tin nhắn chứ sao lại server tạo ra tin nhắn nhỉ?
Mình cũng không rõ là bạn dùng hệ thống tin nhắn này phần server bạn viết luôn hay dựa trên một nền tảng có sẵn kiểu như email server, bạn chỉ gửi đúng cú pháp và nó phân phối tin cho bạn. Nếu hệ thống phức tạp thì bạn chỉ nên viết/ làm phần server hoặc phần client mà thôi, chứ chưa đủ trình để “full-stack” đâu. Còn không thì chỉ mang tính concept, qui mô nhỏ để trình bày giải pháp chứ không làm sản phẩm ngon lành máng lợn nổi, nó quá phức tạp với một lập trình viên mới vào nghề.
Mình đồ rằng bạn đang nhầm nhọt ở cái việc khi INSERT một biểu ghi vào table trong cơ sở dữ liệu và bạn dùng trường ID là số Interger tự tăng auto-incresement vì bản chất là bạn KHÔNG HIỂU VỀ PRIMARY KEY khi thiết kế cơ sở dữ liệu => kết luận rằng “server là nơi tạo tin nhắn”. Dẫn đến là việc bạn rối trong việc quản lý các tin nhắn, cái này lại là yếu kém, không có kiến thức về queue và/ hoặc stack trong lập trình nên mới có cái chuyện “làm thế nào để biết đó là tin nhắn 1 chứ không phải 2, 3”.
Hơn nữa, dường như bạn đang không có nền tảng về cấu trúc dữ liệu + giải thuật và cũng không có kiến thức về network + WWW. Cho nên, mình không hiểu là bạn định thiết lập hệ thống nhắn tin bằng gì. Đọc qua không rõ nó dùng giao thức gì, thuộc loại stateful hay stateless và trên nền web hay là ứng dụng desktop/ mobile?
Chi bằng, cách dễ nhất đó là bạn lên GitHub tải về một phần mềm chat nguồn mở viết bằng ngôn ngữ lập trình mà bạn đang dùng về nghiên cứu để xem người ta làm điều đó như thế nào. Ở đó sẽ giải đáp hầu hết những gì bạn thắc mắc.
3 Likes
Ứng dụng chat bình thường bạn à. Hỗ trợ private chat và group chat.
Tạo tin nhắn ở đây ý mình là dùng để lưu vào database.
Mình làm toàn bộ server và client. Mặc dù làm để học nhưng không giống mấy project kiểu “simple chat app” như trên mạng mà phải đầy đủ tính năng chính như Facebook, Zalo.
Nếu không tìm hiểu và làm thử thì làm sao nâng cao kỹ năng được bạn. Như mình nói ở trên mình không làm project mang tính concept mà phải real-world.
Cái này mình thừa nhận không biết nên mình mới đi hỏi để giải quyết.
Cái này mình cũng thừa nhận hiểu không sâu.
Mình dùng SignalR dựa trên WebSocket để gửi nhận tin nhắn. Client hỗ trợ đa nền tảng gồm web, mobile native và cross-platform.
Nói như bạn thì cũng giống như kêu mình bỏ tiền ra thuê người làm. Mình cũng tham khảo open source để xem phương pháp làm.
3 Likes
Cảm ơn bạn. Mình sẽ tìm đọc thêm. Đọc qua sơ đồ của bạn thì mình nãy ra ý tưởng là. Khi client gửi tin nhắn thì sẽ gửi kèm 1 subscriptionID để khi server nhận được tin nhắn thì sẽ trả lại kèm subscriptionId đó để client nhận dạng được tin nhắn đã gửi. có thể cách implement cũng giống id tạm nhưng cách này mang tính giải thuật hơn.
83% thành viên diễn đàn không hỏi bài tập, còn bạn thì sao?