Nebula Research and Development

What are Sockets?

 

When you make a phone call to an office you use a phone number. That's like an IP address. The receptionist answers and asks "how may I direct your call?" If you say "extension 1234" that is exactly the same as providing a socket number to a server. You know that at extension 1234 there is someone who can respond to your specific inquiry. It will be futile to call extension 4567 and ask questions that pertain to another extension.

If you would like to pursue development of new interfaces to and from your business applications, please let us know. See our contact page, or e-mail .

We tell server programs to listen on a socket/extension for an inbound connection. The client must know which socket on the server it's connecting to. The client may refer to a server process by name. A phone caller may ask for Mr. Jones and the receptionist will look up a list of employees, find Mr. Jones at ext 1234 and transfer the call. The /etc/hosts file does the same thing. When you say "http://..." or "ftp://" or "telnet ..." you are not providing a socket number but the name will translate to a well known socket number (in those cases, 80, 21, and 23 respectively).

When you call from your office, you also have an extension. Calling someone else, your caller ID may show your main line number, not your extension number. A server sees the client's IP address as well as a client socket number. In communications the client can have a fixed or dynamic socket which is used to call various services. Your phone extension is fixed, but client software generally uses a pseudo-random socket. For example, browse to some web site, then open a DOS window and type 'netstat'. You'll see a local address like MyHost:1023 meaning your system is using socket 1023 to connect to the remote site. If you make another connection and then do another netstat, you'll probably see a different client socket ID.

So what is a socket really? It's a pipeline from one system to another. The server has code to open one end and listen for "something". The client has a responsibility to open its end, call down to the server end, and then send a message that the server should understand. The server needs to process that "something" and then (usually) close the connection. The "something" is a protocol, an agreed upon language. You call my phone, I answer and say hello, you say hello, I ask how are you, you say 'fine' or 'not good', I say bye, you say bye, I hang up, you hang up. That's a protocol. Anyone who deviates from the protocol shouldn't be calling - or they might be a hacker trying to see if anyone is home.

Application guys don't care about sockets or protocols. At Nebula R&D, we write client and server interfaces, and allow application guys to call through a pipeline without knowing the underlying plumbing. Our services mostly revolve around allowing many different kinds of clients to access existing MV business apps. We'll keep coming up with new interfaces as long as there are new client technologies, like cell phones, PDAs, wireless tablet PCs, etc. We also do the plumbing to allow other programs (like MS Office apps) to function as clients or servers with your MV app. All we have to do is write the socket code and then create an API (Application Program Interface) on both ends to make the communication easy for the app guys, sort of like putting a comfortable earpiece and mouthpiece on the phone so that people can talk into it.

 
 

© 2009 Nebula Research and Development

Home | About Us | News | FAQ | Products
Services | Articles | Contact Us | Search Site

E-mail for Product and Service inquiries.
Please report site issues to . Thank you!