network.h

Post Reply
kazzmir
Posts: 3
Joined: Tue Oct 18, 2011 8:06 am

network.h

Post by kazzmir » Tue Oct 18, 2011 8:11 am

I just finished getting my program to compile with libogc's network.h (although I haven't tested the functionality just yet). I had to hack a few things in my program to get it to compile. It would be nice if network.h had a closer API to POSIX so I don't need extra #ifdef's.

1. Why the net_ prefix on all the functions? I had to do
#define send net_send
#define accept net_accept
...

2. I had to provide dummy functions for getsockname, gethostbyaddr, getsockopt. The last one seems like an omission from libogc since net_setsockopt exists.

3. Not a huge deal but it would be nice to provide the same headers as linux: net/select.h, netinet/in.h, netinet/tcp.h, arpa/inet.h.

WinterMute
Site Admin
Posts: 1845
Joined: Tue Aug 09, 2005 3:21 am
Location: UK
Contact:

Re: network.h

Post by WinterMute » Thu Oct 20, 2011 12:16 pm

The net_ prefix originally came from the lwip port we did for gamecube and the wii updates were just made compatible with that.

I'd actually really, really like to provide some standard headers and use standard function names instead, we did that for dswifi and it makes porting things a lot easier.

On IRC you mentioned the possibility of supplying patches which would be much appreciated if you have the time to look into it.

I'm not a big fan of using defines to change function names tbh, what might be better is to use function attributes to create the standard functions as aliases for the net_ prefixed functions. The standard headers can just be added to the gc folder in SVN although I'm not 100% sure about close offhand. For dswifi I had to replace this with closesocket because it's not hooked into the open/close functions from fcntl.h.
Help keep devkitPro toolchains free, Donate today

Personal Blog

tueidj
Posts: 40
Joined: Thu Dec 10, 2009 9:26 am

Re: network.h

Post by tueidj » Fri Oct 21, 2011 5:35 am

I don't see how that would work. The standard functions known as close, read, write, ioctl, fcntl, select etc. are all defined to operate on file descriptors which are not the same thing as libogc's network sockets. What happens if someone uses write() in one function to output to a file and tries to use it in another function to write to a socket? Or even worse, combines FDs from different sources in a call to select() (or the wii equivalent, poll()) ?

(btw, net_poll() is broken on wii. IOS uses POLLOUT=0x0008, POLLERR=0x0020, POLLHUP=0x0040, POLLNVAL=0x0080.)

Seems like it would make more sense to rewrite the network code so sockets actually behave like FDs i.e. give them their own devoptab and (finally!) add an ioctl function pointer member to devoptab_t.

WinterMute
Site Admin
Posts: 1845
Joined: Tue Aug 09, 2005 3:21 am
Location: UK
Contact:

Re: network.h

Post by WinterMute » Fri Oct 21, 2011 9:36 pm

I didn't particularly mean close, read, write, ioctl, fcntl, select etc so much as send, sendto, sendmsg, recv, recvmsg, recvfrom, socket etc.

At some point I guess we're crossing the line from a posix like API on baremetal to something that resembles an OS in it's own right. The question is do we want to go that far?

I'd certainly like to see things progress to the point where we can use configure to build cyassl or curl.
Help keep devkitPro toolchains free, Donate today

Personal Blog

Post Reply

Who is online

Users browsing this forum: No registered users and 14 guests