5. GetSMSStatus (Pull)
7.6 SMS Bandwidth
Nó thường được yêu cầu, băng thông tối thiểu yêu cầu về Gateway SMS cho các kết nối tin nhắn SMS IP là gì? Câu hỏi này rất khó trả lời, bởi vì các yêu cầu băng thông phụ thuộc vào nhiều hoàn cảnh. Trong tài liệu này, chúng ta có thể tìm thấy thông tin về những gì ảnh hưởng được yêu cầu và tính toán ví dụ để cung cấp cho bạn một ý tưởng.
Các yêu cầu băng thông phụ thuộc vào những điều sau đây: - SMS kích thước tin nhắn
- SMS giao thức được sử dụng (SMPP, UCP, HTTP, vv) - Có kết nối VPN sử dụng hay không
- Có thông tin liên lạc khác trên cáp bạn sử dụng
Chúng ta hãy giả sử chúng ta gửi 120-160 ký tự trong tin nhắn SMS dài qua giao thức SMPP. Một tin nhắn SMS trung bình mất khoảng 2 Kbytes. Có nghĩa là trên một dòng 128 Kbps ISDN bạn có thể chuyển 8 tin nhắn mỗi thứ hai. (128 Kbps / 8 bit = 16 Kbyte / giây)
Trong tài liệu này nhóm có đề cập một ví dụ tính toán băng thông cho phép bạn xem như thế nào khả năng băng thông của Ozeki NG SMS Gateway hoạt động.
Trong trường hợp kết nối SMPP có một khả năng băng thông 5 MPS (tin nhắn Per Second), 5 MPS đề cập đến một thực tế là khả năng tin nhắn đi và đến với nhau sẽ có 5 tin nhắn / giây.
SMPP connection with 5 MPS
incoming + outgoing messages = 5 messages / second
Xin lưu ý rằng trong tất cả các ví dụ dưới đây nó được giả định rằng không có tin nhắn gửi đến và không có báo cáo kết quả
Nếu bạn đi đến tab"SQL for sending" của người sử dụng cơ sở dữ liệu, bạn có thể tìm thấy tùy chọn này: "Kiểm tra các bảng ozekimessageout mỗi ... giây cho các tin nhắn gửi đi." (Hình 7.6.1). Theo mặc định giá trị này được thiết lập để "10". Trong thực tế nó có nghĩa là người sử dụng cơ sở dữ liệu sẽ kiểm tra "ozekimessageout" bảng các thông điệp trong mỗi 10 giây.
Dưới đây về tab "SQL for sending" bạn cũng có thể tìm thấy "Số lượng tối đa của tin nhắn để gửi với một cuộc thăm dò:" tùy chọn. Theo mặc định nó được thiết lập để "10". Nó đề cập đến số lượng tối đa của tin nhắn được gửi đi với một cuộc thăm dò. Trong thực tế nó có nghĩa là 10 tin nhắn sẽ được gửi đi với một "tùy chọn" tuyên bố. Vì vậy, với các thiết lập mặc định trong Ozeki NG SMS Gateway 10 thông điệp được gửi trong mỗi 10 giây sẽ mất 2 giây với kết nối MPS 5.
Hình 7.6.1 Ví dụ tính băng thông gửi tin nhắn
Ví dụ 1 :
Hình 7.6.1 Ví dụ tính băng thông gửi tin nhắn
Nếu bạn thiết lập thời gian kiểm tra bảng ozekimessageout cho thư gửi đi đến một giá trị thấp hơn - ví dụ như "5" - và bạn để lại số mặc định của tin nhắn được gửi đi (10 tin nhắn) nó cũng sẽ mất 2 giây với 5 MPS kết nối (hình 2). Trong trường hợp này quá trình đòi hỏi cùng một khoảng thời gian nhưng người sử dụng sẽ kiểm tra
"ozekimessageout" bảng cho thư gửi đi thường xuyên hơn (trong mỗi "5" giây thay vì "10").
Ví dụ 2:
Giả sử rằng chúng ta muốn gửi 1000 tin nhắn (với 5 kết nối SMPP MPS).
Nếu bạn sử dụng các thiết lập của "Ví dụ 1": kiểm tra người sử dụng các thông điệp trong mỗi "5" phút và tối đa "10" tin nhắn có thể được gửi đi với một cuộc thăm dò sau đó 100 cuộc thăm dò được yêu cầu để gửi ra các thông điệp. Khi người sử dụng kiểm tra "ozekimessageout" bảng trong mỗi "5" giây nó cần 500 giây (phút 8,3) để thăm dò ý kiến và gửi 1000 tin nhắn. Vì vậy, có đủ thời gian để gửi tin nhắn giữa hai cuộc thăm dò.
Chương 8. CẤU HÌNH EMAIL PHP 8.1 Gửi Email SMTP 1: Download https://code.google.com/a/apache-extras.org/p/phpmailer/downloads/list 2: Document https://code.google.com/a/apache-extras.org/p/phpmailer/w/list 3: Code <?php require_once('../class.phpmailer.php');
//include("class.smtp.php"); // optional, gets called from within class.phpmailer.php if not already loaded
$mail=new PHPMailer(true); // the true param means it will throw exceptions on errors, which we need to catch
$mail->IsSMTP(); // telling the class to use SMTP
try{
$mail->Host ="mail.yourdomain.com"; // SMTP server
$mail->SMTPDebug =2; // enables SMTP debug information (for testing)
$mail->SMTPAuth = true; // enable SMTP authentication
$mail->SMTPSecure ="tls"; // sets the prefix to the servier
$mail->Host = "smtp.gmail.com"; // sets GMAIL as the SMTP server
$mail->Port = 587; // set the SMTP port for the GMAIL server
$mail->Username ="yourusername@gmail.com"; // GMAIL username $mail->Password ="yourpassword"; // GMAIL password
$mail->AddAddress('whoto@otherdomain.com', 'John Doe'); $mail->SetFrom('name@yourdomain.com', 'First Last'); $mail->AddReplyTo('name@yourdomain.com', 'First Last'); $mail->Subject ='PHPMailer Test Subject via mail(), advanced';
$mail->AltBody = 'To view the message, please use an HTML compatible email viewer!'; // optional - MsgHTML will create an alternate automatically
$mail->AddAttachment('images/phpmailer.gif'); // attachment $mail->AddAttachment('images/phpmailer_mini.gif'); // attachment
$mail->Send();
echo"Message Sent OK<p></p>\n";
}catch(phpmailerException $e){
echo$e->errorMessage(); //Pretty error messages from PHPMailer
}catch (Exception $e) {
echo$e->getMessage(); //Boring error messages from anything else! }
?>
8.2 Cấu hình gửi email từ localhostB1: B1:
Hình 7.2: Mở thư viện Openssl B2:
Hình 7.3 Mở thư viện Mod_ssl
Chương 9. CẤU HÌNH HOSTING
Chương này chúng ta cấu hình Cron Jobs trên hosting để gửi SMS tự động Cấu hình cron bobs để thực thi file script php tự động theo thời gian
9.1. Host CpenalB1. Chọn Cron jobs B1. Chọn Cron jobs
9.2 Kloxo
B1. Đăng nhập vào trang quản trị kloxo chọn Cron Scheduled Tasks
B2. Add Simple và tạo lệnh comment giống Cpenal
9.3 DirectadminB1. Chọn Cronjobs B1. Chọn Cronjobs
B2. Tạo một Cron jobs
B3. Nhấn nút Addd
9.4 Plesk
B1. Chọn Subscriptions
B2. Chọn Control Panel
B3. Chọn Website & Domains
B5. Chọn scheduled Tasks
B8. Tạo Scheduled Tasks
Chương 10. MINH HỌA HÊ THỐNG
1. Minh họa thời khóa biểu a. Theo Tháng
2. Đăng ký môn học – Tín chỉ
4. Kết Quả học tập
6. Đăng ký môn học
8. Import danh sách tin nhắn
Chương 11: KIỂM TRA VÀ ĐÁNH GIÁ HỆ THỐNG 10.1 Xây dựng kịch bản kiểm tra
Vì đây là lĩnh vực nghiên cứu và triển khai ứng dụng thực tế, nên hệ thống phải kiểm thử trên mô hình dữ liệu thực tế mới đảm bảo tính ứng dụng và độ ổn định cao. Chương này sẽ trình bày một kịch bản, được xây dựng dựa trên những mẫu dự liệu thực tế. Với sự tham gia của tất cả các đối tượng có liên quan đến hệ thống. Qua đó dễ dàng kiểm tra, đánh giá khả năng và hiệu quả hoạt động của hệ thống.
Kịch bản kiểm thử được sử dụng dữ liệu mẫu là hoạt động giảng dạy của học kỳ 1 và học kỳ 2 năm học 2012- 2013 của trường Đại học Giao Thông Vận Tải Tp. Hồ Chí Minh. Hệ thống được kiểm thử cho cả học chính quy và liên thông. Các bước được triển khai mô hình dữ liệu kiểm thử được mô tả chi tiết như sau:
• Sau khi đã có thời khóa biểu giảng dạy:
o Giảng viên: Hủy giảng -> SMS đến sinh viên hoặc phụ huynh
o Phòng đạo tạo đổi ngày giờ học, đổi phòng học - > gửi SMS tự động cho sinh viên hoặc phụ huynh.
o Phòng đào tạo import điểm - > gửi SMS tự động cho sinh viên hoặc phụ huynh.
Sau khi hoàn thành các bước ở trên, lúc này, hệ thống đã có đầy đủ thông tin cần thiết của học kỳ và sẵn sàng cung cấp các dịch vụ cần thiết để điều hành, kiểm tra và đánh giá trong quá trình hoạt động giảng dạy.
10.2 Dữ liệu kiểm tra
Như đã đề cập ở trên, dữ liệu để kiểm tra hệ thống là dữ liệu thực tế của trường đang hoạt động. Thời khóa biểu của học kỳ 1 chính quy với hơn 800 môn học, thời
khóa biểu học kỳ 2 chính quy với hơn 1000 môn học và cả học kỳ của các lớp liên thông và tại chức. Dữ liệu kiểm tra cũng cho phép sử dụng các cơ sở khác nhau mà trường đang sử dụng để đào tạo. Các đối tượng liên quan tham gia đánh giá hệ thống như: trưởng phòng đào tạo và nhân viên phòng, trưởng phòng quản trị thiết bị và nhân viên, trưởng phòng thanh tra và nhân viên, trưởng khoa, tổ trưởng bộ môn, giảng viên cơ hữu và thỉnh giảng.
Trong quá trình diễn ra hoạt động giảng dạy, nếu có sự thay đổi điều chỉnh về phòng học, hủy báo giáng, đăng ký dạy bù, hay bỏ dạy các đối tượng liên quan phải cung cấp cho hệ thống biết. Khi đó chúng ta cần những thông tin gì về hoạt động giảng dạy thì hệ thống nhanh chóng đáp ứng những yêu cầu đó một cách nhanh chóng.
10.3 Kết quả kiểm tra
Với kịch bản kiểm tra đã giới thiệu ở trên, chúng ta mong đợi hệ thống sẽ đem lại sự tiện lợi, giải quyết những khuyết điểm đang tồn đọng. Và sau khi cho hệ thống hoạt động trong suốt các học kỳ 1 và học kỳ 2 ta có được những kết quả như sau:
- Khi phòng đào tạo đưa thời khóa biểu lên thì tất cả các khoa và tổ bộ môn có liên quan môn học cũng nhận được thời khóa biểu của riêng mình (Không nhận chung như gửi file excel) và phòng thanh tra cũng như phòng quản trị thiết bị cũng nhận được thời khóa biểu của cả học kỳ.
- Khi ban quản lý khoa hoặc tổ trưởng bộ môn phân công giảng viên giảng dạy
xong thì thời khóa biểu sẽ đến từng giảng viên giảng dạy (kể cả giảng viên thỉnh giảng) và thông tin giảng viên dạy môn đó cũng được cập nhật tức thời tới phòng đào tạo, phòng thanh tra.
- Giảng viên vào hệ thống hủy báo giảng (Hiện tại hệ thống chấp nhận hủy không cần xét duyệt), hệ thống sẽ cập nhật vào danh sách hủy báo giảng của
phòng đào tạo. Và thời khóa biểu của ngày học đó của bên thanh tra đào tạo và phòng quản trị thiết bị sẽ không có môn học này. Hiện tại, thông tin này chưa thông báo tức thời đến sinh viên.
- Khi giảng viên đăng ký hủy giảng thì hệ thống đề xuất ngày dạy bù. Thông tin dạy bù sẽ được cập nhật vào danh sách nghỉ và dạy bù của phòng đào tạo đợi xét duyệt. Thông tin chi tiết ngày nghỉ và dạy bù vẫn được lưu vết trong chi tiết của môn học đó. Phòng đào tạo và quản lý khoa cũng có thể xem thông tin này. Khi phòng đào tạo duyệt ngày dạy bù mà giảng viên đã đề xuất thì ngày bù đó sẽ được cập nhật tức thời vào thời khóa biểu của ngày học đó tới giảng viên và các phòng thanh tra và quản trị thiết bị. Chức năng kiểm tra phòng đề xuất bù có bị trùng hay kkhông thì chưa được phát triển.
- Hệ thống cho phép phân quyền đến từng thành viên trong các phòng ban, khoa, tổ trưởng bộ môn và giảng viên. Mỗi người tham gia hệ thống với vai trò và nhiệm vụ khác nhau sẽ có những quyền hạn và chức năng khác nhau. - Chức năng sinh viên tham gia đánh giá chất lượng môn học, như đã đề xuất
ban đầu, vẫn chưa phát triển.
Mục đích kiểm tra là xem xét khả năng đáp ứng của hệ thống với yêu cầu. Kết quả đạt được như trên là đáp ứng được yêu cầu ban đầu đề ra. Có thể giải quyết được nhiều vấn đề đang tồn đọng. Tóm lại, hầu hết các yêu cầu ban đầu hệ thống đều có thể đáp ứng được.
Chương 11: KẾT LUẬN 11.1 Kết luận
Từ mục tiêu ban đầu, đề tài nghiên cứu đã đề xuất và phát triển được một hệ thống theo dõi giảng dạy cho trường ĐH GTVT Tp. HCM. Hệ thống được xây dựng dựa trên những nhu cầu cấp thiết của trường và tham khảo những tính năng hay của một số hệ thống khác. Về cơ bản hệ thống có thể đưa vào sử dụng chính thức.
Với hệ thống được đề xuất ở trên, nó được sử dụng cho tất cả các đối tượng liên quan tham gia vào tổ chức, theo dõi và thực hiện cũng như đánh giá hoạt động giảng dạy. Hệ thống được phát triển trên nền Web và đưa lên Server nên các đối tượng liên quan có thể sử dụng bất cứ lúc nào và bất cứ đâu chỉ cần có kết nối Internet.
Hệ thống TMS được tích hợp những chức năng như sau: thông báo hủy báo giảng, thông báo dạy bù, thông báo đổi phòng học, thông báo đổi ngày học, thông báo điểm, thông báo tin tức, import danh sách sinh viên, danh sách tin nhắn cho từ trường hợp thông qua SMS hoặc email. Cho phép theo dõi cập nhật tình hình giảng dạy hàng ngày. Từ những thông tin đầy đủ ở trên hệ thống sẵn sàng đáp ững những yêu cầu như:
Thống kê tình hình giảng dạy của các khoa, của giảng viên ...
Tóm lại, với việc xây dựng tich hợp hệ thống SMS vào hệ thống TMS, đề tài nghiên cứu đã có những đóng góp nổi bật mà hệ thống trước kia không đáp ứng được như sau:
• SMS chạy trên nền Web, cho phép giao tiếp và liên hệ trực tiếp giữa các đối tượng liên quan tham gia vào quá trình giảng dạy như: PĐT, TTĐT, QTTB,
Khoa và tổ bộ môn, giảng viên cơ hữu và thỉnh giảng.
• Những việc trước kia phải lưu trữ bằng file, ghi nhớ bằng con người và xử lý bằng tay. Thì bây giờ hệ thống TMS sẽ quản lý việc lưu trực, tự động thực hiện những việc theo yêu cầu.
11.2 Hướng mở rộng
Trong quá trình thực hiện đề tài này, với sự ràng buộc về thời gian nhất định, nhóm đã cố gắng hoàn thành một cách tốt nhất những mục tiêu đề ra và đã có những thành quả nhất định. Tuy nhiên, hệ thống SMS vẫn còn nhiều hướng có thể được mở rộng và phát triển thêm nhằm đáp ứng nhu cầu hiện tại tốt nhất. Dưới đây là một vài đề xuất để có thể mở rộng cho dịch vụ SMS:
• Hệ thống SMS hiện tại đã được kiểm chứng với mẫu dữ liệu đúng, để hệ thống hoạt động ổn định và chịu lỗi cao thì cần phải kiểm tra kỹ với mẫu dữ liệu sai.
• Hệ thống SMS này tích hợp được nhiều hệ thống dịch vụ khác chạy chung để sử dụng SMS , thiết lập chung, chạy song song.
• Cần có from gửi tin nhắn từ web để có thể truy cập trên Desktop, Mobile
TÀI LIỆU THAM KHẢO
6. Fibosms Vệt Nam http://www.fibosms.com/
7. Server SMS gateway http://gateway.sms.vn/
8. kernel http://www.kannel.org/
9. http://inet.vn/san-pham/inet-sms-gateway-3-0-tong-dai-tin-nhan-2883.html
10. http://www.bulksms.com/int/
11 Ozeki NG SMS Gateway http://www.ozekisms.com/
Ebook
Fibo_SMS_API v2.2.pdf Fibo_PUSH SMS_vn.pdf Fibo_SMS_PrivateNumber.pdf
SMSHosting - Push ClientCommingSMS.pdf SMSHosting - Push SMS Status.pdf
Source Code
File đính kèm CD-ROM Video Clip
LỜI CẢM ƠN
Chúng tôi xin chân thành cảm ơn Khoa Công nghệ Thông Tin trường Đại Học Giao Thông Vận Tải TP.Hồ Chí Minh đã tạo điều kiện cho chúng tôi thực hiện đồ án thực tập này.
Chúng tôi xin chân thành cảm ơn Th.S Đặng Nhân Cách đã tận tình hướng dẫn, chỉ bảo chúng tôi trong suốt thời gian thực hiện luận văn tốt nghiệp này. Chúng tôi cũng xin cảm ơn quý Thầy Cô đã tận tình giảng dạy, trang bị cho