200 OK SwatantrAI

Web applications were originally developed around a client/server model, where the Web client is always the initiator of transactions, requesting data from the server. Thus, there was no mechanism for the server to independently send, or push, data to the client without the client first making a request.

To overcome this deficiency, Web app developers can implement a technique called HTTP long polling, where the client polls the server requesting new information. The server holds the request open until new data is available. Once available, the server responds and sends the new information. When the client receives the new information, it immediately sends another request, and the operation is repeated. This effectively emulates a server push feature.

Considerations for HTTP Long Polling

There are a couple of things to consider when using HTTP long polling to build realtime interactivity in your application, both in terms of developing and operations/scaling.

As usage grows, how will you orchestrate your realtime backend?
When mobile devices rapidly switch between WiFi and cellular networks or lose connections, and the IP address changes, does long polling automatically re-establish connections?
With long polling, can you manage the message queue and catch up missed messages?
Does long polling provide load balancing or failover support across multiple servers?

When building a realtime application with HTTP long polling for server push, you’ll have to develop your own communication management system. This means that you’ll be responsible for updating, maintaining, and scaling your backend infrastructure.

Backend Infrastructure for Realtime Functionality

With these considerations in mind, that’s where a realtime data stream network comes in. This data stream network takes care of the backend infrastructure for you, so you don’t have to worry about maintaining and orchestrating your realtime network.

When looking at HTTP long polling with the goal of streaming data, PubNub is a low-latency and low-overhead realtime Web app communication environment, and features the ability to send messages to a single client, client groups and all clients. Upgrading to PubNub is both rapid and easy since it is based on a publish/subscribe model.

Key Benefits of Protocol Agnostic Realtime Messaging

Instead of relying solely on HTTP long polling for realtime messaging, a protocol-agnostic approach is beneficial. PubNub automatically chooses the best protocols and frameworks depending on the environment, latency, etc. Any server or client code wanting to communicate makes a single API call to publish or subscribe to data channels.

The code is identical between clients and servers, making implementation much simpler than using HTTP long polling. In terms of connection management, the network handles network redundancy, routing topology, loading balancing, failover, and channel access. Additionally, it offers core building blocks for building realtime into your application.

Presence – Detect when users enter/leave your app and whether machines are online
Storage & Playback – Store realtime message streams for future retrieval and playback
Mobile Push Gateway – Manage the complexities of realtime apps on mobile devices, including Push Notifications
Access Management – Fine grain Publish and Subscribe permissions down to the person, device or channel
Security – Secure all communications with enterprise-grade encryption standards
Analytics – Leverage visualizations into your realtime data streams
Data Sync – Sync application state across clients in realtime

'Coz sharing is caring

What Is Sendmail?

sendmail is a very plain and simple MTA (Mail Transfer Agent), which implements the SMTP (Simple Mail Transfer Protocol) amongst others and can be used to transmit emails, typically on Linux. While there is a commercial version available which is called “Sendmail”, the sendmail we’re covering in this how-to article is the UNIX-based version of it, which comes with pretty much every Linux distribution as well as *BSD (FreeBSD, OpenBSD, and variants). Using the sendmail command might be the easiest way to send e-mails via Linux shell CLI (Command Line Interface), apart from mailx, which can be used in conjunction with sendmail to make it even easier to send and receive emails from the command line. Like the name already suggests, sendmail itself can only send emails and not store received ones in POP or IMAP mailboxes.

Where Is Sendmail And Its Configuration Files Located?

The first interesting information that we might need for testing sendmail is the path of the binary file that gets executed if we issue the command sendmail on our command line. To figure that out, we’ll use the which command as shown below:

[root@box ~]# which sendmail
/usr/sbin/sendmail

The above output means that the full path to our sendmail command’s binary file is /usr/sbin/sendmail which you should note for the steps further below.

If you want to adjust the configuration files of sendmail, you can usually find them in the directory /etc/mail/on UNIX (FreeBSD, OpenBSD) and Linux (CentOS, Fedora, Debian, Ubuntu) systems. The main configuration file of sendmail is /etc/mail/sendmail.cf, however adjusting that is not part of this tutorial. A good place for more information is the manual page of sendmail, that you can view by running the command man sendmail. Now to the interesting part of this sendmail command line tutorial.

How to Test the Sendmail Command On Linux

To quickly test if the sendmail command is working correctly to then use it for example in shell scripts, via command line or even from PHP scripts (PHP supports sendmail to send emails from PHP scripts – you can set the sendmail path in your php.ini), you can issue the below command on your UNIX or Linux system:

echo "Subject: sendmail test" | sendmail -v my@email.com

my@email.com is obviously the e-mail address you want the test email to be sent to. This sendmail command line example will send a blank email with the subject “sendmail test” to my@email.com if the test is successful. You can also send longer e-mails containing a subject, body and additional headers if you want to, but just to test if sendmail works that’s usually not required. Still, here is how you can do that:

1.) Create a file called mail.txt (or anything you like) in ~/mail.txt with vim or nano or your preferred text editor

2.) Paste the following content to it, but of course adjusting the email addresses, as those are just sendmail command examples:

To: my@email.com
Subject: sendmail test two
From: me@myserver.com

And here goes the e-mail body, test test test..

3.) At last we send the e-mail template we just created with: sendmail -vt < ~/mail.txt

That’s it – you can now test sendmail from the command line and even send full e-mails including headers from Linux/UNIX shell. Below is an example of how the simple sendmail test could look like on a live system:

Sendmail And Spam

One thing I’d like to add is that due to the fact that PHP and other scripts can usually access the sendmail binaries, it can also be used to send out spam and phishing mails and that’s what can happen on shared servers where accounts were compromised through an outdated CMS or weak passwords. If you want to find out which script or POSIX user is sending the spam with sendmail, you can issue the below command and pay close attention to the output:

ps faux | grep sendmail

Sendmail Conclusion

While sendmail can pose a few risks on shared or insecure systems, it is a great lightweight MTA that can be used to send e-mails from shell scripts, PHP applications or even directly the command line. It also automatically negotiates STARTTLS for encrypted transmission of the emails if the remote SMTP server supports it, which is a useful security practice.

'Coz sharing is caring