Okay, first things first. SignalR is not a server-side-only technology. It also lives on the client. That's its selling point. It abstracts the heavy lifting of damn-near-real-time communication between client and server. Wasn't sure if that was clear given the question title.
With that out of the way, if you're interested in how SignalR works, then yes, one of its approaches is to send an occasional request to the server to see if anything's changed. That's called ajax long polling. It's not SignalR's first strategy because, well, it kinda stinks. Just think of all the things that could go wrong. Not to mention it's not a real-time two-way update since the server can't initiate a change. SignalR prefers to use Websockets if they're available.
They call it a fallback strategy. SignalR tries an HTML5 technology like WebSockets. If that's not available, it falls back to one of the old Comet tricks. Pretty smart, really.
SignalR is definitely not the only game in town. Other options span from cool projects like Meteor (Meteor is a lot more than real-time client/server communication, it's pretty huge) to more focused projects like socket.io. Keep in mind that since bidirectional communication requires both a client and server, each project uses different server technology. Since you mention SignalR, I'm going to guess you're using (or are considering) a Microsoft technology. In that case, you have fewer options.
If what you're really asking is how to implement bespoke bidirectional client/server communication, then start with WebSockets (tutorial). If you have many users, you'll probably find that some of them are using older tech that doesn't support WebSockets (or maybe you're using older server tech that doesn't support it). In that case, take a look at Comet (tutorial). By the time you get all of that done (or imagine the time it would take), SignalR might look better to you.