1

I've looked over the Classes that seem relevant but it is not clear that there is a Class equivalent to Pipe that is for TCP/UDP sockets. The Socket class description seems to not just do what you need to create and bind a port and set up listening. At the moment I've implemented this in straight unix networking primitives... but it would be nice if I Socket were really the same API as Pipe.

How do others deal with this? Am I mistaken in what Socket does?

This is a case where I don't want complexity, just a standard OO cover to standard IP networking.

rob mayoff
  • 375,296
  • 67
  • 796
  • 848
Dale Amon
  • 219
  • 2
  • 5

1 Answers1

1

I haven't used GNUstep in a while, so this is based off of Apple's libraries, and you will need to make sure there are no differences.

TCP connections can be created using a class method on NSStream, which returns an input stream and output stream for communication.

NSHost *host = ...;
NSUInteger port = ...;
NSInputStream *input;
NSOutputStream *output;
[NSStream getStreamsToHost:host port:port inputStream:&input
                                         outputStream:&output];

For other connections, you can create the connection using the standard Unix API, then create a NSFileHandle to wrap the file descriptor.

int fd = socket(...);
NSFileHandle *fileHandle = [[NSFileHandle alloc] initWithFileDescriptor:fd
                                                         closeOnDealloc:YES];
ughoavgfhw
  • 39,734
  • 6
  • 101
  • 123
  • yeah last I checked, they had pretty good parity in foundation, but that was like 8 years ago... but all that stuff was in foundation 8 years ago, So... I think anything that you write with that layer should be pretty much the same in OS X or GnuStep – Grady Player Feb 22 '14 at 01:55
  • Can the two ports be the same? I've got an application level protocol that returns an ACK or NAK msg depending on the success of the remote operation. (and it is working fairly well with unix calls, so I'd rather not change things. – Dale Amon Feb 22 '14 at 01:57
  • @DaleAmon if you have nice portable posix code working then don't re-write it with NSBlahBlah wrappers... you won't gain anything. – Grady Player Feb 22 '14 at 02:16
  • @Dale Do you mean having the input and output stream be one object? No, you can't do that. You could use a file handle for bidirectional communication. But paraphrasing Grady, there is nothing wrong with using C code in Objective-C, so if you already have it working feel free to leave it as is. – ughoavgfhw Feb 22 '14 at 03:49
  • The advantage of library objects is that someone is constantly working to make them more stable and fool proof whilst keeping a stable API... over time you gain more functionality without ever changing your code. That's why I was hoping there were stable covers over Unix networking. And in fact why there *should* be such capabilities. If I were still in the same sort of work I was 25 years ago, that's probably the first thing I'd have designed, an abstraction layer that covered all of Posix and standard features. Then I'd have layered a fancier abstraction layer over that. – Dale Amon Feb 22 '14 at 21:18
  • Seems to be a different design philosophy at work and I am not quite sure what it is. – Dale Amon Feb 22 '14 at 21:19
  • Note: in about another month a bunch of boxes of old stuff of mine will arrive, which include the complete NS manual sets from v1,v2 and v3... I'm going to be interested to see what they supported... if my memory does not fail me, there was a much more complete set of useful data structure objects and primitives in the various kits than seems to be available at present. I wonder if it is just that folks have not had time to implement the full NeXT API, or if it mutated into a different direction. – Dale Amon Feb 22 '14 at 21:29