I'm having problems with sockets

In article <BD33229F.2FC2%stuart.rogers.at.clara.co.uk@deadmail.com>,
Stuart Rogers <stuart.rogers.at.clara.co.uk.RemoveThis@deadmail.com> wrote:

> My problem is that I want to use a *specific* port
> number - I'm working on a Usenet client, and IIRC NNTP usually uses
> port 119.

On most Unix systems, only the superuser is allowed to allocate ports in
this range.

On Mon, 2 Aug 2004, Stuart Rogers wrote:

> "Michael Ash" <mike DeleteThis @mikeash.com> wrote:
>
>> However, for an NNTP *client*, you don't need to listen on any ports at
>> all, you need to connect to the NNTP server. For that, you'd use a method
>> like -initRemoteWithTCPPort:host:.
>
> I know, but as I don't have a permanently on internet connection
> I wanted to make a local test rig that my main code could talk to
> before letting it loose on innocent news servers.

Gotcha. That certainly seems reasonable.

>> However Part 2, NSSocketPort is intended for use with NSConnection and
>> does not make a good way to do raw TCP communications. If you don't need
>> compatibility below OS X 10.3, check out NSStream.
>
> NSStream is something that's missed my stream of consciousness,
> but I'll certainly check it out. I haven't tried using NSConnection
> as all the example source code I've found using it dealt specifically
> with local inter-app communications, rather than talking to a strange
> and foreign server. Not only that, but none of these examples
> was clear on how messages are sent and returned from an NSConnection.

NSConnection does normally work with Mach ports for local inter-app
communication, but it can be used with NSSocketPort to communicate with
apps on a remote machine. The catch, however, is that both sides must be
using Cocoa and NSConnection on the link; you can't use NSConnection to
talk to an NNTP server or any other "normal" TCP server program.

NSConnection sends and receives messages by using proxy objects that
forward messages. Once a conneciton is set up, you can do something like:

id obj = [connection rootProxy];
[obj someMethodWithObj:x andThing:y]; // gets sent to the other program

Of course, this doesn't help your particular case at all.

>> If you do, you can
>> either use raw sockets with the C-based API, or you can use one of the
>> many third-party ObjC sockets libraries, of which several are linked to
>> here: <http://www.cocoadev.com/index.pl?SocketClasses>.
>
> I am aware of such things, but (a) this is for me an exercise in
> Obj-C, and (b) I want to keep my reliance on third party material
> to a minimum, in the hope of maximising my learning. Otherwise,
> that's a perfectly good suggestion!
>
> Thanks for your help - I can stop tearing my hair out now.

I'm happy to be of service.

"Michael Ash" <mike.RemoveThis@mikeash.com> wrote:
>
> On Sun, 1 Aug 2004, Stuart Rogers wrote:
>
>> When I try to create a socket port like this:
>>
>> incomingSocket = [[NSSocketPort alloc] initWithTCPPort:PORT_NUMBER];
>>
>> I find that 'incomingSocket' only gets created if PORT_NUMBER is zero
>> (i.e incomingSocket==nil).
>>
>> For a zero value, according to Foundation.pdf, a port number is selected
>> by the system. My problem is that I want to use a *specific* port
>> number - I'm working on a Usenet client, and IIRC NNTP usually uses
>> port 119. [<snip>]
>
> On unix systems, only root is allowed to open ports for listening below
> 1024. That is why your initialization is failing.

D'oh! And in one move we see the limits of my knowledge of sockets!
Thanks!

> However, for an NNTP *client*, you don't need to listen on any ports at
> all, you need to connect to the NNTP server. For that, you'd use a method
> like -initRemoteWithTCPPort:host:.

I know, but as I don't have a permanently on internet connection
I wanted to make a local test rig that my main code could talk to
before letting it loose on innocent news servers.

> However Part 2, NSSocketPort is intended for use with NSConnection and
> does not make a good way to do raw TCP communications. If you don't need
> compatibility below OS X 10.3, check out NSStream.

NSStream is something that's missed my stream of consciousness,
but I'll certainly check it out. I haven't tried using NSConnection
as all the example source code I've found using it dealt specifically
with local inter-app communications, rather than talking to a strange
and foreign server. Not only that, but none of these examples
was clear on how messages are sent and returned from an NSConnection.

> If you do, you can
> either use raw sockets with the C-based API, or you can use one of the
> many third-party ObjC sockets libraries, of which several are linked to
> here: <http://www.cocoadev.com/index.pl?SocketClasses>.

I am aware of such things, but (a) this is for me an exercise in
Obj-C, and (b) I want to keep my reliance on third party material
to a minimum, in the hope of maximising my learning. Otherwise,
that's a perfectly good suggestion!

Thanks for your help - I can stop tearing my hair out now.

Stuart

"Michael Ash" <mike.TakeThisOut@mikeash.com> wrote:
>
> On Mon, 2 Aug 2004, Stuart Rogers wrote:
>
>> "Michael Ash" <mike.TakeThisOut@mikeash.com> wrote:
>>
>>> However Part 2, NSSocketPort is intended for use with NSConnection and
>>> does not make a good way to do raw TCP communications. If you don't need
>>> compatibility below OS X 10.3, check out NSStream.
>>
>> NSStream is something that's missed my stream of consciousness,
>> but I'll certainly check it out. I haven't tried using NSConnection
>> as all the example source code I've found using it dealt specifically
>> with local inter-app communications, rather than talking to a strange
>> and foreign server. Not only that, but none of these examples
>> was clear on how messages are sent and returned from an NSConnection.
>
> NSConnection does normally work with Mach ports for local inter-app
> communication, but it can be used with NSSocketPort to communicate with
> apps on a remote machine. The catch, however, is that both sides must be
> using Cocoa and NSConnection on the link; you can't use NSConnection to
> talk to an NNTP server or any other "normal" TCP server program.

That was the conclusion I had drawn - thanks for confirming it.

>> Thanks for your help - I can stop tearing my hair out now.
>
> I'm happy to be of service.

Look out for more stupid questions! (Assuming work doesn't
get in the way of my programming attempts.)

Stuart

Stuart Rogers wrote:
>> However, for an NNTP *client*, you don't need to listen on any ports
>> at all, you need to connect to the NNTP server. For that, you'd use
>> a method like -initRemoteWithTCPPort:host:.
>
> I know, but as I don't have a permanently on internet connection
> I wanted to make a local test rig that my main code could talk to
> before letting it loose on innocent news servers.

there are two options. first, if you're writing your client for general
consumption, it should allow itself to be configured to use server ports
other than 119. sometimes a company will set up an nntp server for
internal use that uses a non-standard port number for security reasons.
at the very least, you could set up compile-time defines that allow you
to build a version of your client that's hard-coded to some port other
than 119. then you can configure your client and server to agree on
some port number that's greater than 1000, so you've gotten around the
unix security problem.

the other solution is to run your server simulator using 'sudo', which
will give it access to low-numbered ports.

On Tue, 3 Aug 2004, Stuart Rogers wrote:

> I've just been taking a look at the documentation for NSStream
> that Michael pointed out (AFAIK it's only documented on Apple's
> online docs - it's not filtered down into any off-line PDFs).
> They look quite simple to use, and geared towards my needs.

I don't know about the PDFs, I don't use them, but I have the full
NSStream documentation available in Xcode's documentation window.

"Jøhnny Fävòrítê (it means "halo, then resonate")" <this.is.DeleteThis@fake.com>
wrote:
>
> Stuart Rogers wrote:
>>> However, for an NNTP *client*, you don't need to listen on any ports
>>> at all, you need to connect to the NNTP server. For that, you'd use
>>> a method like -initRemoteWithTCPPort:host:.
>>
>> I know, but as I don't have a permanently on internet connection
>> I wanted to make a local test rig that my main code could talk to
>> before letting it loose on innocent news servers.
>
> there are two options. first, if you're writing your client for general
> consumption, it should allow itself to be configured to use server ports
> other than 119. sometimes a company will set up an nntp server for
> internal use that uses a non-standard port number for security reasons.
> at the very least, you could set up compile-time defines that allow you
> to build a version of your client that's hard-coded to some port other
> than 119. then you can configure your client and server to agree on
> some port number that's greater than 1000, so you've gotten around the
> unix security problem.

I was planning to have a user-configurable port, but at the
moment I'm in a hard-coded quick'n'dirty experimental phase.

> the other solution is to run your server simulator using 'sudo', which
> will give it access to low-numbered ports.

Hmm... As much as I trust my own programming skills, I think
I'll *not* use sudo for experimenting!

I've just been taking a look at the documentation for NSStream
that Michael pointed out (AFAIK it's only documented on Apple's
online docs - it's not filtered down into any off-line PDFs).
They look quite simple to use, and geared towards my needs.

Stuart

"Michael Ash" <mike RemoveThis @mikeash.com> wrote:
>
> On Tue, 3 Aug 2004, Stuart Rogers wrote:
>
>> I've just been taking a look at the documentation for NSStream
>> that Michael pointed out (AFAIK it's only documented on Apple's
>> online docs - it's not filtered down into any off-line PDFs).
>> They look quite simple to use, and geared towards my needs.
>
> I don't know about the PDFs, I don't use them, but I have the full
> NSStream documentation available in Xcode's documentation window.

I'm pretty sure the pdf I downloaded today didn't mention them,
and the version I've been working from up to know certainly
doesn't. I find the PDFs easier to navigate than the webby-
style docs. But I'm weird like that.

Stuart.