Sockets are full-duplex communication
channels between processes either
local to the same host machine or
where one process is on a remote host.
Unlike pipes, in which data goes in
one direction only, sockets allow
processes both to send and receive
data. NSFileHandle facilitates
communication over stream-type sockets
by providing mechanisms run in
background threads that accept socket
connections and read from sockets.
NSFileHandle currently handles only
communication through stream-type
sockets. If you want to use datagrams
or other types of sockets, you must
create and manage the connection using
native system routines.
The process on one end of the
communication channel (the server)
starts by creating and preparing a
socket using system routines. These
routines vary slightly between BSD and
non-BSD systems, but consist of the
same sequence of steps:
Create a stream-type socket of a
certain protocol.
Bind a name to the socket.
Adding itself as an observer of
NSFileHandleConnectionAcceptedNotification.
Sending acceptConnectionInBackgroundAndNotify
to this file handle object.
This method accepts the connection in the
background, creates a new NSFileHandle
object from the new socket descriptor,
and posts an NSFileHandleConnectionAcceptedNotification.
Now I saw Michael answer .
About the differences between “stream-type” socket and a “datagram” socket type
Do you have iPhone implementation example for native system routines(datagram-socket-type)?
Ok first I found what I needed, with CFSocket API which will allow me to implement UDP Synchronization.
CFSocket API
Sockets are the most basic level of network communications. A socket acts in a similar manner to a telephone jack. It allows you to connect to another socket (either locally or over a network) and send data to that socket.
The most common socket abstraction is BSD sockets. CFSocket is an abstraction for BSD sockets. With very little overhead, CFSocket provides almost all the functionality of BSD sockets, and it integrates the socket into a run loop. CFSocket is not limited to stream-based sockets (for example, TCP), it can handle any type of socket.
You could create a CFSocket object from scratch using the CFSocketCreate function, or from a BSD socket using the CFSocketCreateWithNative function. Then, you could create a run-loop source using the function CFSocketCreateRunLoopSource and add it to a run loop with the function CFRunLoopAddSource. This would allow your CFSocket callback function to be run whenever the CFSocket object receives a message.
Regardless I found AsyncSocket API.
CocoaAsyncSocket supports TCP and UDP. The AsyncSocket class is for TCP, and the AsyncUdpSocket class is for UDP. Each class is described below.
AsyncSocket is a TCP/IP socket networking library that wraps CFSocket and CFStream. It offers asynchronous operation, and a native cocoa class complete with delegate support. Here are the key features:
Queued non-blocking reads and writes, with optional timeouts. You tell it what to read or write, and it will call you when it's done.
Automatic socket acceptance. If you tell it to accept connections, it will call you with new instances of itself for each connection. You can, of course, disconnect them immediately.
Delegate support. Errors, connections, accepts, read completions, write completions, progress, and disconnections all result in a call to your delegate method.
Run-loop based, not thread based. Although you can use it on main or worker threads, you don't have to. It calls the delegate methods asynchronously using NSRunLoop. The delegate methods include a socket parameter, allowing you to distinguish between many instances.
Self-contained in one class. You don't need to muck around with streams or sockets. The class handles all of that.
Support for TCP streams over IPv4 and IPv6.
The library is public domain, originally written by Dustin Voss. Now available in a public setting to allow and encourage its continued support.
AsyncUdpSocket is a UDP/IP socket networking library that wraps CFSocket. It works almost exactly like the TCP version, but is designed specifically for UDP. This includes queued non-blocking send/receive operations, full delegate support, run-loop based, self-contained class, and support for IPv4 and IPv6.
CocoaAsyncSocket
And here is the CFSocket Reference
CFSocket Reference
Related
What is the actual difference between Socket and RPC (Remote Procedure Call)?
As per my understanding both's working is based on Client–server model. Also which one should be used in which conditions?
PS: Confusion arise while reading Operating System Concepts by Galvin
Short answer:
RPC is the protocol. The socket provides access to the transport to implement that protocol.
RPC is the service and protocol offered by the operating system to allow code to be triggered for running by a remote application. It has a defined protocol by which procedures or objects can be accessed by another device over a network. An implementation of RPC can be done over basically any network transport (e.g. TCP, UDP, cups with strings).
The socket is just a programming abstraction such that the application can send and receive data with another device through a particular network transport. You implement protocols (such as RPC) on top of a transport (such as TCP) with a socket.
It is operating system specific. So read first a good OS book like Operating Systems: Three Easy Pieces (freely downloadable).
Network sockets are a way to do some inter-process communication (notably between different machines). Read also about Berkeley sockets API, e.g. socket(7) on Linux.
Remote procedure calls are a programming technique (often using socket(2) system call on Linux). Every RPC request expects exactly one reply and is software initiated.
Sockets are often also used for asynchronous messages (for example, the X11 protocols stack, WebSockets, SMTP). Message passing is a programming paradigm (more general than RPC), they are sent often without expecting any reply. For example, the X11 server would send a keyboard event message for every key press, etc.
(so in some ways, you are comparing apples and oranges)
If on Linux, I recommend reading Advanced Linux Programming (freely downloadable), and reading more about syscalls(2) (notably poll(2) for multiplexing)
PS: Confusion arise while reading Operating System Concepts by Galvin
That's your problem right there.
A remote procedure call (RPC) is high level model for network communication. There are numerous RPC protocols in existence. In the RPC model, your underlying implementation creates a stub for each remote procedure. When your application calls the "remote procedure" the stub packs up the parameters, sends them over the network, invokes, the remote version of the procedure, takes the return values and send them back over the network to the caller, the stub unpacks the return values and your application then receives them.
The RPC model became hip in the late 1980's. The idea was that it would be transparent where your functions actually executed (in your process, in another process, on another computer). This concept expanded into distributed objects around the early 1990's (e.g., DCOM, CORBA).
Unfortunately, in the real world applications really needed to know if a procedure was executing remotely because of delay and error handling.
Somewhere in the the RPC implementation a network interface gets called.
Sockets are such a network interface. They are not the only programming interface but they are the most common on Unix systems.
Thus, an RPC MIGHT be implemented using a socket.
I am trying to implement a multimedia server application in NS-3 which can serve multiple clients.
Can a single NS-3 (TCP? and/or) UDP socket accept multiple simultaneous connections?
As stated in the ns-3 socket documentation, all socket calls in ns-3 are non-blocking (in contrast to the original socket API). This is a direct result of the asynchronous and event-based implementation model of ns-3.
The core concept to model a blocking socket call is to register a call-back which is invoked once a connection is established or data becomes available. One of these calls is ns3::Socket::SetRecvCallback which you can use to react to incoming packets
Of course, ns-3 can be used to implement a server that accepts multiple connections. For this purpose, you need to register to a call-back function such as ns3::Socket::SetRecvCallback and then to dispatch the received data adequately.
I've spent a few days looking for different solutions, but the whole area is quite complicated, and I'm wondering if anybody knows of any project where I can simply transfer NSData or an NSString or some other simple file over wifi to another iPhone on the network?
Np. Use bonjour to search for devices. Then use CocoaAsyncSocket to send and receive data. It works like a charm.
Little info about AsyncSock:
GCDAsyncSocket and AsyncSocket are TCP/IP socket networking libraries.
Here are the key features available in both:
Native objective-c, fully self-contained in one class. No need to muck
around with sockets or streams. This class handles everything for you.
Full delegate support Errors, connections, read completions, write
completions, progress, and disconnections all result in a call to your
delegate method.
Queued non-blocking reads and writes, with optional timeouts. You tell
it what to read or write, and it handles everything for you. Queueing,
buffering, and searching for termination sequences within the stream -
all handled for you automatically.
Automatic socket acceptance. Spin up a server socket, tell it to
accept connections, and it will call you with new instances of itself
for each connection.
Support for TCP streams over IPv4 and IPv6. Automatically connect to
IPv4 or IPv6 hosts. Automatically accept incoming connections over
both IPv4 and IPv6 with a single instance of this class. No more
worrying about multiple sockets.
Support for TLS / SSL Secure your socket with ease using just a single
method call. Available for both client and server sockets.
In a nutshell, I am trying to write a C++ XPCOM component which listens on a UDP port and calls a callback function (a javascript function) every time a UDP packet arrives.
Sorry if the answer is too obvious but I was wondering what are the ways to listen on a UDP port with Mozilla (Preferably something easy to do)?
I know that there is an interface called nsIServerSocket which allows some listeners to be attached to it, but this is only for opening TCP ports. Is there any UDP equivalent of this (where I can attach a listener which is notified every time a UDP packet arrives)?
I also know that I could probably use PR_OpenUDPSocket and such. Is there a way of using this without dealing with threads? (As far as I understand I have to return to the calling javascript function after opening the port).
Thanks.
Why do you need to restrict yourself to Mozilla's API if you are writing C++ code? You can use the POSIX socket API directly, see How to set up a Winsock UDP socket? for a WinSock example (the only difference for Linux and OS X should be that WSAStartup() call is unnecessary). nsIServerSocket is mainly useful for JavaScript code that doesn't have the option to use the system libraries directly.
If you prefer a straight answer to your question: no, there is no XPCOM API to create UDP sockets. You already found the NSPR API (PR_OpenUDPSocket()) but it is probably designed with DNS communication in mind since that's pretty much the only UDP communication a browser would do. Don't expect much here.
And a side-note: you might want to avoid binary XPCOM components and create a native library that can be called via js-ctypes instead. See here for the details.
For an UDP server architecture that will have long-lived connections, one architecture is to have one socket that listens to all incoming UDP traffic, and then create separate sockets for each connection using connect() to set the remote address. My question is whether it is possible to do this atomically similar to what accept() does for TCP.
The reason for creating a separate socket and using connect() is that this makes it easy to spread the packet-processing across multiple threads, and also make it easier to have the socket directly associated with the data structures that are needed for processing.
The demultiplexing logic in the networking stack will route the incoming packets to the most specific socket.
Now my question is basically what happens when one wants to emulate accept() for UDP like this:
Use select() with a fd-set that includes the UDP server-socket.
Then read a packet from the UDP server-socket.
Then create a new UDP socket which is then connect()ed to the remote address
I call select() with a fd-set that includes both sockets.
What is returned?
given that a packet arrives to the OS somewhere between 1 and 3.
Will the packet be demultiplexed to the UDP server-socket, or will it be demultiplexed to the more specific socket created in 3. That is, at what point does demultiplexing take place? When the packet arrives, or must it happen "as if" it arrived at point 4?
Follow-up question in case the above does not work: What's the best way to do this?
I see that this discussion is from 2009, but since it keeps popping up when I search, I thought I should share my approach. Both to get some feedback and because I am curios about how the author of the question solved the problem.
The way I chose emulate UDP-accept was a combination of number one and two in nik's answer. I have a root thread which listens on a given socket. I have chosen to use TCP for simplicity, but changing this socket to UDP is not very hard. When a client wants to "connect" to my server using UDP, it first connects to the TCP socket and requests a new connection.
The root thread then proceeds by creating a UDP socket, binds it to a local interface, does connect and sets up data structures. This file descriptor is then passed to the thread that will be responsible for the connection. The IP/port information of the new UDP socket is passed back to the client, which creates a new UDP socket and sends data to the provided IP/port.
This approach works well for my use, but the additional steps for setting up a flow introduces an overhead. In some cases, this overhead might not be acceptable.
I found this question after asking it myself here...
UDP server and connected sockets
Since connect() is available for UDP to specify the peer address, I wonder why accept() wasn't made available to effectively complete the connected UDP session from the server side. It could even move the datagram (and any others from the same client) that triggered the accept() over to the new descriptor.
This would enable better server scalability (see the rationale behind SO_REUSEPORT for more background), as well as reliable DTLS authentication.
This will not work.
You have two simple options.
Create a multi-threaded program that has a 'root' thread listening on the UDP socket and 'dispatching' received packets to the correct thread based on the source. This is because you want to segregate processing by source.
Extend your protocol so the the sources accept an incoming connection on some fixed port and then continue with the protocol communication. In this case you would let the source request on the standard UDP port (of your choice), then your end will respond from a new UDP socket to the sources' UDP port. This way you have initiated a new UDP path from your end backwards to the known UDP port of each source. That way you have different UDP sockets at your end.