- App On Port 6000 Not Working On Mac Osx Catalina
- App On Port 6000 Not Working On Mac Osx Mojave
- App On Port 6000 Not Working On Mac Osx High Sierra
- App On Port 6000 Not Working On Mac Osx 10
Basically when you say 'open a port' its a several step process. 1) Configure & Start your application (ie Apache). 2) Verify the application is listening on the port: from commandline netstat -a grep 8080 3) Turn off firewall(s). Bottom line is an application needs to be listening on that port for the whole process to work. Native Mac apps built with Mac Catalyst can share code with your iPad apps, and you can add more features just for Mac. In macOS Big Sur, you can create even more powerful versions of your apps and take advantage of every pixel on the screen by running them at native Mac resolution. Apps built with Mac Catalyst can now be fully controlled using just the keyboard, access more iOS. OS X v10.5.1 and later include an application firewall you can use to control connections on a per-application basis (rather than a per-port basis). This makes it easier to gain the benefits of firewall protection, and helps prevent undesirable apps from taking control of network ports open for legitimate apps.
These are instructions on how to build Code::Blocks under Apple Mac OS X.They have been tested under Mac OS X version 10.4 (PowerPC and Intel),and should work similarly on the newer Mac OS X 10.5 and 10.6 as well.
We will be building everything from scratch using the source code, andnot use any available package managers likeMacPorts,Fink,Gentoo orRPM.Packaging can be done later, once it has reached a more stable release.
Update: building for MacPorts can be found at the end of the document.
- 2Check Autotools versions
- 7Build wxWidgets
- 8Bundle library for Mac
- 10Build CodeBlocks from SVN
- 11Bundle application for Mac
- 11.1Way One: Mac OS (resource)
- 11.2Way Two: NeXT (bundle)
- 13Install with MacPorts
Install Developer Tools
If they didn't come bundled with Mac OS X, get the Xcode Tools (or Developer Tools for older Mac OS X) from http://developer.apple.com/tools/ or from your install disk.
This will install Apple versions of:
- http://www.gnu.org/software/gcc/ (GNU Compilers)
- http://www.gnu.org/software/gdb/ (GNU Debugger)
- http://www.gnu.org/software/make/ (GNU Make)
Apple regularly pulls all older links in order to promote newer Mac OS X, but all theold developer tools can be downloaded from ADC at http://connect.apple.com/
You need a (free) developer registration with Apple first, in order to log in there.For Mac OS X 10.4, you want (at least) Xcode 2.2, since earlier versions were buggy.
Check Autotools versions
Depending on your OS version, you might need to download and compile new versions of these:
- http://www.gnu.org/software/autoconf/ (GNU Autoconf)
- http://www.gnu.org/software/automake/ (GNU Automake)
- http://www.gnu.org/software/libtool/ (GNU Libtool)
Check what you have, with --version (note that GNU libtool is called 'glibtool' on Mac OS X)
Currently Code::Blocks requires versions:
- autoconf 2.50+
- automake 1.7+ (1.9+ needed in order to build the dist tarball)
- libtool 1.4+ (1.5.8+ highly recommended to get some bug fixes)
Automake example
How to open a app file on mac. For Mac OS X 10.4, you will only need an upgraded (local) installation of automake 1.9.x.
You can download 'automake-1.9.6.tar.gz' and configure and install it with something like:
Since it's now known as 'automake-1.9', it won't interfere with the regular 'automake'
If you would rather have the new version to be called when calling 'automake', let it install into /usr/local and put /usr/local/bin before /usr/bin in your PATH.
Libtool example
Download libtool source. The following instructions will overwrite your current version of libtool with the one you just downloaded.
Note that this will replace the system version of glibtool, which might have some compatibility issues with building other software.
FYI: Universal Binaries
If you are building for Mac OS X 10.4 or later, you might want to build 'Universal Binaries 'These are binaries that contain code for both PowerPC ('ppc' arch) and Intel ('i386' arch)
The basic flags that needs to be added are:
(You only need the sysroot parameter on PowerPC Macintosh, not on a Intel Macintosh)The '-arch i386 -arch ppc' is what tells the compiler to build a 'universal' (or 'fat') binary.
Usually it's easiest to build one version for 'powerpc-apple-darwin8',and one version for 'i686-apple-darwin8', and then merge them with 'lipo'
Some caveats:
- pre-compiled headers might fail with a 'no main' error. If they do, add a -c to only compile them
- when cross-compiling, tools like auto_revision might fail to build. copy these from a native build
- the Tiger compilers might crash from time to time, but that is only to be expected (it seems)..
See Technical Note TN2137: Building Universal Binaries from 'configure'-based Open Source Projects
FYI: Compilers
When building for older versions of the SDK, you want to make sure to use the same compiler.
Mac OS X 10.6 has GCC 4.2 as the default compiler, which won't work for the Mac OS X 10.4 SDK.
FYI: ANSI or UNICODE
For the moment we are using 'ANSI' (--disable-unicode, default) for Mac OS X 10.3 and earlier,and 'UNICODE' (--enable-unicode, optional) for Mac OS X 10.4 and later.
See http://www.wxwidgets.org/manuals/stable/wx_unicode.html#unicodeandansi
FYI: 32-bit or 64-bit
Code::Blocks currently uses wxMac (wxOSX/Carbon), which is 32-bit only. So it's not possible to build for 'x86_64'.
When Code::Blocks (and requirements) has been updated to use wxOSX/Cocoa, then a 64-bit version might be built too.
Build wxWidgets
Download the source code
Download the tarball for the wxMac release:
Apply necessary patches
Don't forget to apply any released patches!
Configure and (GNU) Make
note: the easiest way to build a Universal Binary with wxWidgets isthe new flag: --enable-universal_binary (you need wxWidgets 2.6.4+)
Install into Destination
Bundle library for Mac
To avoid having the Code::Blocks user having to compile or install wxWidgets themselves,we can bundle it with our application so that it is contained in the application bundle.This could also be done by statically linking wxWidgets, but with dynamic linking we canshare the wxWidgets library between all applications using wxWidgets (not just Code::Blocks)
Way One: Library (dynamic)
To bundle our shared library with the application, we include it in 'MacOS' and change the path:
@executable_path will be replaced with e.g. /Developer/Applications/CodeBlocks.app/Contents/MacOS
Way Two: Framework (bundle)
To bundle our framework with the application, we include it in 'Frameworks' and change the path:
This way it will first look in the framework path (-F), and then in for the shared library path (-L) as usual.
Install Subversion client
On Mac OS X 10.4, you need to install the Subversion (svn) program:
Note: you need SVN for the Code::Blocks revision scripts to work!
Build CodeBlocks from SVN
Download the source code
Apply necessary patches
For a list of all available patches, see:
You might need to convert line endings from DOS to Unix first.
Bootstrap with Autotools
You need to use the newer version of automake (see above), for the 'bootstrap'. (OS X 10.5 users may have recent enough autotools so they may not need to install them)
Mono Fix
If you have the Mono.framework installed, then it probably set up a symlink like:
Unless you have a 'proper' pkg-config installation the Code::Blocks configure will fail, so move this symbolic link aside.
Configure
Note: the easiest way to build a Universal Binary for Code::Blocks is to build once for PowerPC (-arch ppc) and once for Intel (-arch i386), and then merge them (with lipo) afterwards.
Note: You need to patch the location of the pre-compiled headers, or it will generate them in the same place for both arch.
Tiger Fix
There is a bug in the glibtool of Mac OS X 10.4, that fails to link C++ libs:
To work around this, you need to edit the generated 'libtool' script manually:
This bug has been fixed in GNU libtool 1.5.8 and later.
(GNU) Make
'nice' isn't strictly needed, it just makes the compile run at a lower process priority
For the Universal Binary build:
Install into Destination
'sudo' asks you for an admin password, in order to get install permissions
For the Universal Binary build:
Where 'lipomerge' is a custom shell script:
Bundle application for Mac
After building codeblocks in the regular Unix way, you need to bundle it with the iconsand various other info that it needs to make a regular stand-alone Macintosh application.
There are two ways of accomplishing this, old Mac OS-style resource or NeXT-style bundle.The old resources are handy while developing, while bundles are more suitable for release.
Note: You need to use either of these methods, or your application will launchin the background behind all other windows and will be unable to receive any events!
Way One: Mac OS (resource)
Handy while developing, as you don't need to create a whole bundle.
First we install the program to the PREFIX directory of your choice:
Note: on the Intel Macintoshes, the icon comes up as 'broken'(apparently it assumes that all apps with resforks are Classic)
Start the application with a small prefix shell wrapper like this:
You don't need the 'DYLD_LIBRARY_PATH' stuff,if you are installing to a system directory.
Common PREFIX Settings
Local: PREFIX=/usr/local
System: PREFIX=/usr
MacPorts: PREFIX=/opt/local
Fink: PREFIX=/sw
Way Two: NeXT (bundle)
This does not involve resources, and is more relocatable.
Files needed:
- codeblocks.plist (generated, rename to 'Info.plist')
- codeblocks.sh (shell wrapper, rename to 'CodeBlocks')
- app.icns (icons are available in src/src/resources/icons)
The MacOS program will just be a shell wrapper that calls 'bin/codeblocks', like above.Traditionally the bundle would include Frameworks and Resources, but we'll just avoid thosehere and use the regular 'lib' and 'share/codeblocks' instead (just as with a regular install). These temporary directories are listed in italic below, they're not really used in bundles..
Setup a hierarchy like this, and copy the files from the regular build/install and the above file list to it:
The CodeBlocks application can now be moved with the Finder, and started up like a regular Mac application. (the nightly build includes a more advanced Info.plist and more icons - for also mapping all the files that the application can open, like source code and header files and such)
Proper Application Bundling
To avoid the shell wrapper, the binary can now be moved from 'bin/codeblocks' to 'MacOS/CodeBlocks'. Helper files are moved from 'share/codeblocks' to 'Resources'. The dynamic libraries are moved from 'lib' to 'MacOS':
To avoid having to use a DYLD_LIBRARY_PATH, we rename the shared libraries (with the install_name_tool program) from e.g. /usr/local/lib/ to @executable_path/:
The libraries can have their names changed using the -id parameter:
You also need to change all of the loadable bundles for the plugins:
You can check the result, what libraries/frameworks it links to, with:
Optionally you can then repeat the process, for the wx library too..
Here is a full script to do the job.. It assumes to be executed at the same directory level as the CodeBlockSVN.app directory that will receive all the stuff.. maybe enhanced but it is a first try that do work when packaging an OS X SVN build.
FYI: Darwin vs. Mac OS X
'Darwin is the UNIX technology-based foundation of Mac OS X.'
'Pure Darwin' here refers to the Open Source version of the OS:
- http://puredarwin.org/ or http://gnu-darwin.sourceforge.net/
(that is: Darwin using X11 instead of Aqua for the user interface)
App On Port 6000 Not Working On Mac Osx Catalina
![App On Port 6000 Not Working On Mac Osx App On Port 6000 Not Working On Mac Osx](/uploads/1/3/3/8/133896544/828247234.png)
Install with MacPorts
Install wxWidgets
You will need the wxWidgets library, install as port with:
If you want the X11/GTK version on Mac OS X, instead use:
Install Code::Blocks
After that is installed, you can install Code::Blocks with:
If you want the X11/GTK version on Mac OS X, instead use:
This will download the SVN trunk, and any dependencies:
Note: to upgrade from SVN, you need to uninstall first:
This is both because all SVN versions are numbered '0',but also due to a bug in the Code::Blocks build scripts.
Running +aqua (wxMac) version
After the build completes, you can start the program by:
Note that the wxMac application bundle in 'MacPorts'is just a wrapper, with symbolic links to /opt/local..
Running +x11 (wxGTK) version
The non-bundled wxGTK version is instead started with:
When running X11/wxGTK programs in Mac OS X, you can use'open-x11' to first start up X11.app and set up $DISPLAY:
Retrieved from 'http://wiki.codeblocks.org/index.php?title=Installing_Code::Blocks_from_source_on_Mac_OS_X&oldid=6415'
This article explains how to work with sockets and socket streams at various levels, from POSIX through Foundation.
Important: This article describes ways to make socket connections that are completely under the control of your program. Most programs would be better served by higher-level APIs such as
NSURLConnection
. To learn more about these higher-level APIs, read Networking Overview.The APIs described in this article should be used only if you need to support some protocol other than the protocols supported by built-in Cocoa or Core Foundation functionality.
At almost every level of networking, software can be divided into two categories: clients (programs that connect to other apps) and services (programs that other apps connect to). At a high level, these lines are clear. Most programs written using high-level APIs are purely clients. At a lower level, however, the lines are often blurry.
Socket and stream programming generally falls into one of the following broad categories:
- Packet-based communication—Programs that operate on one packet at a time, listening for incoming packets, then sending packets in reply.With packet-based communication, the only differences between clients and servers are the contents of the packets that each program sends and receives, and (presumably) what each program does with the data. The networking code itself is identical.
- Stream-based clients—Programs that use TCP to send and receive data as two continuous streams of bytes, one in each direction.How to use apple mail app mac pro. With stream-based communication, clients and servers are somewhat more distinct. The actual data handling part of clients and servers is similar, but the way that the program initially constructs the communication channel is very different.
This chapter is divided into sections based on the above tasks:
- Choosing an API Family—Describes how to decide which API family to use when writing networking code.
- Writing a TCP-Based Client—Describes how to make outgoing TCP connections to existing servers and services.
- Writing a TCP-Based Server—Describes how to listen for incoming TCP connections when writing servers and services.
- Working with Packet-Based Sockets—Describes how to work with non-TCP protocols, such as UDP.
Choosing an API Family
The API you choose for socket-based connections depends on whether you are making a connection to another host or receiving a connection from another host. It also depends on whether you are using TCP or some other protocol. Here are a few factors to consider:
![Osx Osx](/uploads/1/3/3/8/133896544/165661231.jpg)
- In OS X, if you already have networking code that is shared with non-Apple platforms, you can use POSIX C networking APIs and continue to use your networking code as-is (on a separate thread). If your program is based on a Core Foundation or Cocoa (Foundation) run loop, you can also use the Core Foundation
CFStream
API to integrate the POSIX networking code into your overall architecture on the main thread. Alternatively, if you are using Grand Central Dispatch (GCD), you can add a socket as a dispatch source.In iOS, POSIX networking is discouraged because it does not activate the cellular radio or on-demand VPN. Thus, as a general rule, you should separate the networking code from any common data processing functionality and rewrite the networking code using higher-level APIs.Note: If you use POSIX networking code, you should be aware that the POSIX networking API is not protocol-agnostic (you must handle some of the differences between IPv4 and IPv6 yourself). It is a connect-by-IP API rather than a connect-by-name API, which means that you must do a lot of extra work if you want to achieve the same initial-connection performance and robustness that higher-level APIs give you for free. Before you decide to reuse existing POSIX networking code, be sure to read Avoid Resolving DNS Names Before Connecting to a Host in Networking Overview. - For daemons and services that listen on a port, or for non-TCP connections, use POSIX or Core Foundation (
CFSocket
) C networking APIs. - For client code in Objective-C, use Foundation Objective-C networking APIs. Foundation defines high-level classes for managing URL connections, socket streams, network services, and other networking tasks. It is also the primary non-UI Objective-C framework in OS X and iOS, providing routines for run loops, string handling, collection objects, file access, and so on.
- For client code in C, use Core Foundation C networking APIs. The Core Foundation framework and the CFNetwork framework are two of the primary C-language frameworks in OS X and iOS. Together they define the functions and structures upon which the Foundation networking classes are built.Note: In OS X, CFNetwork is a subframework of the Core Services framework; in iOS, CFNetwork is a top-level framework.
Writing a TCP-Based Client
The way you make an outgoing connection depends on what programming language you are using, on the type of connection (TCP, UDP, and so forth), and on whether you are trying to share code with other (non-Mac, non-iOS) platforms.
- Use
NSStream
for outgoing connections in Objective-C.If you are connecting to a specific host, create aCFHost
object (notNSHost
—they are not toll-free bridged), then useCFStreamCreatePairWithSocketToHost
orCFStreamCreatePairWithSocketToCFHost
to open a socket connected to that host and port and associate a pair ofCFStream
objects with it. You can then cast these to anNSStream
object.You can also use theCFStreamCreatePairWithSocketToNetService
function with aCFNetServiceRef
object to connect to a Bonjour service. Read Discovering and Advertising Network Services in Networking Overview for more information.Note: ThegetStreamsToHost:port:inputStream:outputStream:
method ofNSNetService
is not available on iOS, and is discouraged on OS X for performance reasons. Specifically,NSNetService
requires you to create an instance ofNSHost
. When you create the object, the lookup is performed synchronously. Thus, it is unsafe to construct anNSHost
object on your main application thread. See NSNetService and Automatic Reference Counting (ARC) for details. - Use
CFStream
for outgoing connections in C.If you are writing code that cannot include Objective-C, use theCFStream
API. It integrates more easily with other Core Foundation APIs thanCFSocket
, and enables the cellular hardware on iOS (where applicable), unlike lower-level APIs. You can useCFStreamCreatePairWithSocketToHost
orCFStreamCreatePairWithSocketToCFHost
to open a socket connected to a given host and port and associate a pair ofCFStream
objects with it.You can also use theCFStreamCreatePairWithSocketToNetService
function to connect to a Bonjour service. Read Discovering and Advertising Network Services in Networking Overview for more information. - Use POSIX calls if cross-platform portability is required.If you are writing networking code that runs exclusively in OS X and iOS, you should generally avoid POSIX networking calls, because they are harder to work with than higher-level APIs. However, if you are writing networking code that must be shared with other platforms, you can use the POSIX networking APIs so that you can use the same code everywhere.Never use synchronous POSIX networking APIs on the main thread of a GUI application. Free photo editing apps mac. If you use synchronous networking calls in a GUI application, you must do so on a separate thread.Note: POSIX networking does not activate the cellular radio on iOS. For this reason, the POSIX networking API is generally discouraged in iOS.
The subsections below describe the use of
NSStream
. Except where noted, the CFStream
API has functions with similar names, and behaves similarly.To learn more about the POSIX socket API, read the UNIX Socket FAQ at http://developerweb.net/.
Establishing a Connection
As a rule, the recommended way to establish a TCP connection to a remote host is with streams. Streams automatically handle many of the challenges that TCP connections present. For example, streams provide the ability to connect by hostname, and in iOS, they automatically activate a device’s cellular modem or on-demand VPN when needed (unlike
CFSocket
or BSD sockets). Streams are also a more Cocoa-like networking interface than lower-level protocols, behaving in a way that is largely compatible with the Cocoa file stream APIs.The way you obtain input and output streams for a host depends on whether you used service discovery to discover the host:
- If you already know the DNS name or IP address of the remote host, obtain Core Foundation read (input) and write (output) streams with the
CFStreamCreatePairWithSocketToHost
function. You can then take advantage of the toll-free bridge betweenCFStream
andNSStream
to cast yourCFReadStreamRef
andCFWriteStreamRef
objects toNSInputStream
andNSOutputStream
objects. - If you discovered the host by browsing for network services with a
CFNetServiceBrowser
object, you obtain input and output streams for the service with theCFStreamCreatePairWithSocketToNetService
function. Read Discovering and Advertising Network Services in Networking Overview for more information.
After you have obtained your input and output streams, you should retain them immediately if you are not using automatic reference counting. Then cast them to
NSInputStream
and NSOutputStream
objects, set their delegate objects (which should conform to the NSStreamDelegate
protocol), schedule them on the current run loop, and call their open
methods.Note: If you are working with more than one connection at a time, you must also keep track of which input stream is associated with a given output stream and vice versa. The most straightforward way to do this is to create your own connection object that holds references to both streams, and then set that object as the delegate for each stream.
Handling Events
When the
stream:handleEvent:
method is called on the NSOutputStream
object’s delegate and the streamEvent parameter’s value is NSStreamEventHasSpaceAvailable
, call write:maxLength:
to send data. This method returns the number of bytes written or a negative number on error. If fewer bytes were written than you tried to send, you must queue up the remaining data and send it after the delegate method gets called again with an NSStreamEventHasSpaceAvailable
event. If an error occurs, you should call streamError
to find out what went wrong.When the
stream:handleEvent:
method is called on your NSInputStream
object’s delegate and the streamEvent parameter’s value is NSStreamEventHasBytesAvailable
, your input stream has received data that you can read with the read:maxLength:
method. This method returns the number of bytes read, or a negative number on error.If fewer bytes were read than you need, you must queue the data and wait until you receive another stream event with additional data. If an error occurs, you should call
streamError
to find out what went wrong.If the other end of the connection closes the connection:
- Your connection delegate’s
stream:handleEvent:
method is called withstreamEvent
set toNSStreamEventHasBytesAvailable
. When you read from that stream, you get a length of zero (0
). - Your connection delegate’s
stream:handleEvent:
method is called withstreamEvent
set toNSStreamEventEndEncountered
.
When either of these two events occurs, the delegate method is responsible for detecting the end-of-file condition and cleaning up.
Closing the Connection
To close your connection, unschedule it from the run loop, set the connection’s delegate to
nil
(the delegate is unretained), close both of the associated streams with the close
method, and then release the streams themselves (if you are not using ARC) or set them to nil
(if you are). By default, this closes the underlying socket connection. There are two situations in which you must close it yourself, however:- If you previously set the
kCFStreamPropertyShouldCloseNativeSocket
tokCFBooleanFalse
by callingsetProperty:forKey:
on the stream. - If you created the streams based on an existing BSD socket by calling
CFStreamCreatePairWithSocket
.By default, streams created from an existing native socket do not close their underlying socket. However, you can enable automatic closing by setting thekCFStreamPropertyShouldCloseNativeSocket
tokCFBooleanTrue
with thesetProperty:forKey:
method.
For More Information
To learn more, read Setting Up Socket Streams in Stream Programming Guide, Using NSStreams For A TCP Connection Without NSHost, or see the SimpleNetworkStreams and RemoteCurrency sample code projects.
Writing a TCP-Based Server
As mentioned previously, a server and a client are similar once the connection is established. The main difference is that clients make outgoing connections, whereas servers create a listening socket (sometimes listen socket)—a socket that listens for incoming connections—then accept connections on that socket. After that, each resulting connection behaves just like a connection you might make in a client.
The API you should choose for your server depends primarily on whether you are trying to share the code with other (non-Mac, non-iOS) platforms. There are only two APIs that provide the ability to listen for incoming network connections: the Core Foundation socket API and the POSIX (BSD) socket API. Higher-level APIs cannot be used for accepting incoming connections.
- If you are writing code for OS X and iOS exclusively, use POSIX networking calls to set up your network sockets. Then, use GCD or
CFSocket
to integrate the sockets into your run loop. - Use pure POSIX networking code with a POSIX-based run loop (
select
) if cross-platform portability with non-Apple platforms is required.If you are writing networking code that runs exclusively in OS X and iOS, you should generally avoid POSIX networking calls because they are harder to work with than higher level APIs. However, if you are writing networking code that must be shared with other platforms, you can use the POSIX networking APIs so that you can use the same code everywhere. - Never use
NSSocketPort
orNSFileHandle
for general socket communication. For details, see Do Not Use NSSocketPort (OS X) or NSFileHandle for General Socket Communication in Networking Overview.
The following sections describe how to use these APIs to listen for incoming connections.
Listening with Core Foundation
To use Core Foundation APIs to listen for incoming connections, you must do the following:
- Add appropriate includes:
- Create socket objects (returned as a
CFSocketRef
object) with theCFSocketCreate
orCFSocketCreateWithNative
function. SpecifykCFSocketAcceptCallBack
as thecallBackTypes
parameter value. Provide a pointer to aCFSocketCallBack
callback function as the callout parameter value. - Bind a socket with the
CFSocketSetAddress
function. Provide aCFData
object containing asockaddr
struct that specifies information about the desired port and family. - Begin listening on a socket by adding the socket to a run loop.Create a run-loop source for a socket with the
CFSocketCreateRunLoopSource
function. Then, add the socket to a run loop by providing its run-loop source to theCFRunLoopAddSource
function.
After this, you can access the underlying BSD socket descriptor with the
CFSocketGetNative
function.When you are through with the socket, you must close it by calling
CFSocketInvalidate
.In your listening socket’s callback function (
handleConnect
in this case), you should check to make sure the value of the callbackType parameter is kCFSocketAcceptCallBack
, which means that a new connection has been accepted. In this case, the data parameter of the callback is a pointer to a CFSocketNativeHandle
value (an integer socket number) representing the socket.To handle the new incoming connections, you can use the
CFStream
, NSStream
, or CFSocket
APIs. The stream-based APIs are strongly recommended.To do this:
- Create read and write streams for the socket with the
CFStreamCreatePairWithSocket
function. - Cast the streams to an
NSInputStream
object and anNSOutputStream
object if you are working in Cocoa. - Use the streams as described in Writing a TCP-Based Client.
For more information, see CFSocket Reference. For sample code, see the RemoteCurrency and WiTap sample code projects.
Listening with POSIX Socket APIs
POSIX networking is fairly similar to the
CFSocket
API, except that you have to write your own run-loop-handling code.Important: Never use POSIX networking APIs on the main thread of a GUI application. If you use POSIX networking in a GUI application, you must either do so on a separate thread or use GCD.
Here are the basic steps for creating a POSIX-level server:
- Create a socket by calling
socket
. For example: - Bind it to a port.
- If you have a specific port in mind, use that.
- If you don’t have a specific port in mind, pass zero for the port number, and the operating system will assign you an ephemeral port. (If you are going to advertise your service with Bonjour, you should almost always use an ephemeral port.)
For example: - If you are using an ephemeral port, call
getsockname
to find out what port you are using. You can then register this port with Bonjour. For example: - Call
listen
to begin listening for incoming connections on that port.
The next steps depend on whether you intend to use pure POSIX socket code or a higher level abstraction.
Handling Events with Core Foundation
Call
CFSocketCreateWithNative
. Then follow the directions in Listening with Core Foundation, beginning at step 3.Handling Events with Grand Central Dispatch
App On Port 6000 Not Working On Mac Osx Mojave
GCD allows you to perform operations asynchronously, and provides an event queue mechanism for determining when to read data from the socket. After creating the listening socket, a GCD-based server should:
- Call
dispatch_source_create
to create a dispatch source for the listening socket, specifyingDISPATCH_SOURCE_TYPE_READ
as the source type. - Call
dispatch_source_set_event_handler
(ordispatch_source_set_event_handler_f
anddispatch_set_context
) to set a handler that gets called whenever a new connection arrives on the socket. - When the listen socket handler is called (upon a new connection), it should:
- Call
accept
. This function fills a newsockaddr
structure with information about the connection and returns a new socket for that connection.If desired, callntohl(my_sockaddr_obj.sin_addr.s_addr)
to determine the client’s IP address. - Call
dispatch_source_create
to create a dispatch source for the client socket, specifyingDISPATCH_SOURCE_TYPE_READ
as the source type. - Call
setsockopt
to set theSO_NOSIGPIPE
flag on the socket. - Call
dispatch_source_set_event_handler
(ordispatch_source_set_event_handler_f
anddispatch_set_context
) to set a handler that gets called whenever the state of the connection changes.
- In the client socket handler, call
dispatch_async
ordispatch_async_f
and pass a block that callsread
on the socket to grab any new data, then handle that data appropriately. This block can also send responses by callingwrite
on the socket.
Handling Events with Pure POSIX Code
- Create a file descriptor set and add new sockets to that set as new connections come in.
- If you need to perform actions periodically on your networking thread, construct a
timeval
structure for theselect
timeout.It is important to choose a timeout that is reasonable. Short timeout values bog down the system by causing your process to run more frequently than is necessary. Unless you are doing something very unusual, yourselect
loop should not wake more than a few times per second, at most, and on iOS, you should try to avoid doing this at all. For alternatives, read Avoid POSIX Sockets and CFSocket on iOS Where Possible in Networking Overview.If you do not need to perform periodic actions, passNULL
. - Call
select
in a loop, passing two separate copies of that file descriptor set (created by callingFD_COPY
) for the read and write descriptor sets. Theselect
system call modifies these descriptor sets, clearing any descriptors that are not ready for reading or writing.For thetimeout
parameter, pass thetimeval
structure you created earlier. Although OS X and iOS do not modify this structure, some other operating systems replace this value with the amount of time remaining. Thus, for cross-platform compatibility, you must reset this value each time you callselect
.For thenfds
parameter, pass a number that is one higher than the highest-numbered file descriptor that is actually in use. - Read data from sockets, calling
FD_ISSET
to determine if a given socket has pending data.Write data to callingFD_ISSET
to determine if a given socket has room for new data.Maintain appropriate queues for incoming and outgoing data.
As an alternative to the POSIX
select
function, the BSD-specific kqueue
API can also be used to handle socket events.For More Information
To learn more about POSIX networking, read the
socket
, listen
, FD_SET
, and select
manual pages.Working with Packet-Based Sockets
The recommended way to send and receive UDP packets is by combining the POSIX API and either the
CFSocket
or GCD APIs. To use these APIs, you must perform the following steps:- Create a socket by calling
socket
. - Bind the socket by calling
bind
. Provide asockaddr
struct that specifies information about the desired port and family. - Connect the socket by calling
connect
(optional).Note that a connected UDP socket is not a connection in the purest sense of the word. However, it provides two advantages over an unconnected socket. First, it removes the need to specify the destination address every time you send a new message. Second, your app may receive errors when a packet cannot be delivered. This error delivery is not guaranteed with UDP, however; it is dependent on network conditions that are beyond your app’s control.
From there, you can work with the connection in three ways:
App On Port 6000 Not Working On Mac Osx High Sierra
- If you are using GCD for run loop integration (recommended), create a dispatch source by calling
dispatch_source_create
. Assign an event handler to the dispatch source. Optionally assign a cancellation handler. Finally, pass the dispatch source to thedispatch_resume
function to begin handling events. - If you are using
CFSocket
for integration, this technique is somewhat more complicated, but makes it easier to interface your code with some Cocoa APIs. However,CFSocket
objects use a single object to represent a connection (much like sockets at the POSIX layer), whereas most Cocoa APIs are designed to interface with stream-based APIs that use separate objects for sending and receiving. As a result, some Cocoa APIs that expect read or write streams may be difficult to use in conjunction withCFSocketRef
objects.To useCFSocket
:- Create an object to use for managing the connection. If you are writing Objective-C code, this can be a class. If you are writing pure C code, this should be a Core Foundation object, such as a mutable dictionary.
- Create a context object to describe that object.
- Create a
CFSocket
object (CFSocketRef
) for theCFSocketNativeHandle
object by callingCFSocketCreateWithNative
.Be sure to set (at minimum) thekCFSocketDataCallBack
flag in yourcallBackTypes
parameter value. Do not set thekCFSocketAcceptCallBack
flag.You’ll also need to provide a pointer to aCFSocketCallBack
callback function as the callout parameter value.For example: - Tell Core Foundation that it is allowed to close the socket when the underlying Core Foundation object is invalidated.
- Create an event source for the socket and schedule it on your run loop.
Whenever new data becomes available, the data handler callback gets called. In your callback, if the value of the callbackType parameter iskCFSocketConnectCallBack
, check the data parameter passed into the callback. If it isNULL
, you have connected to the host. You can then send data using theCFSocketSendData
function.When you are finished with the socket, close and invalidate it by calling theCFSocketInvalidate
function.At any point, you can also access the underlying BSD socket by calling theCFSocketGetNative
function.For more information, see CFSocket Reference. For sample code, see the UDPEcho sample code project. - If you are using pure POSIX sockets, use the
select
system call to wait for data, then use theread
andwrite
system calls to perform I/O. To learn more about sending and receiving UDP packets with the POSIX socket API, read the UNIX Socket FAQ at http://developerweb.net/.
Obtaining the Native Socket Handle for a Socket Stream
Sometimes when working with socket-based streams (
NSInputStream
, NSOutputStream
, CFReadStream
, or CFWriteStream
), you may need to obtain the underlying socket handle associated with a stream. For example, you might want to find out the IP address and port number for each end of the stream with getsockname
and getpeername
, or set socket options with setsockopt
.To obtain the native socket handle for an input stream, call the following method:
You can do the same thing with an output stream, but you only need to do this with one or the other because the input and output streams for a given connection always share the same underlying native socket.
Note: If you are working with a Core Foundation stream, you can do the same thing with
CFReadStreamCopyProperty
, CFDataGetLength
, and CFDataGetBytes
.App On Port 6000 Not Working On Mac Osx 10
Copyright © 2013 Apple Inc. All Rights Reserved. Terms of Use | Privacy Policy | Updated: 2013-09-17