TCP\UDP operations from native layer

[Omer Gilad]

Hello,
Is there a stable API for TCP\UDP networking from the NDK? My searches
seem futile so far.
Basically, I want to be able to send and receive TCP and UDP packets,
and have some minimal control, like setting TCP_NO_DELAY.

Thanks!

[Dmitry Moskalchuk]

BSD sockets

See build/platforms/android-*/arch-arm/usr/include/sys/socket.h

Dmitry Moskalchuk

06.07.2010 13:17, Omer Gilad пишет:

[Tim Mensch]

Dmitry Moskalchuk wrote:
> BSD sockets
>
> See build/platforms/android-*/arch-arm/usr/include/sys/socket.h
Is there a set of man pages or other searchable documentation that
includes only exactly what is available on Android? Or is the best
approach to just grep for commands in the include tree and look at
standard Linux man pages when you find a command?

Tim

__________ Information from ESET NOD32 Antivirus, version of virus signature database 5256 (20100706) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

[Clayton Hughes]

Tim,

$NDK/docs/STABLE-APIS.TXT isn't searchable, but it tells you exactly
what you can use and what you can't: You get all of the standard C
library, math, and a few select tidbits of C++.

Because sockets isn't part of the C lib or otherwise mentioned in the
stable-apis, I'd be hesitant to use it.

[Tim Mensch]

Clayton Hughes wrote:

$NDK/docs/STABLE-APIS.TXT isn't searchable, but it tells you exactly
what you can use and what you can't:  You get all of the standard C
library, math, and a few select tidbits of C++.

Because sockets isn't part of the C lib or otherwise mentioned in the
stable-apis, I'd be hesitant to use it.

Hold on. This is EXACTLY why I want a definitive list of APIs that are stable.

I know about STABLE-APIS.TXT. It does say:

> The kernel-specific headers in <linux/...> and <asm/...> are not considered
> stable at this point. Avoid including them directly because some of them
> are likely to change in future releases of the platform. This is especially
> true for anything related to specific hardware definitions.

But we're talking about sys/socket.h. It appears to be defined in Bionic, so it is part of the C library. In fact, the man page for socket doesn't say it requires an additional link library, so I think it's standard on Linux that it's part of the C library--correct me if I'm wrong.

But the point is that I'm not a sufficient Linux guru to just know what calls are part of the C library or what calls are kernel-specific. And it doesn't say NOT to use them, but just to "avoid using them directly."

And if sys/socket.h is also likely out of bounds, then STABLE-APIS.TXT doesn't even give the slightest hint that might be true. So either my interpretation is wrong, and sys/socket.h is somehow "kernel related" in a way that will break in future versions, or your interpretation is wrong, and it's perfectly fine to use it, but in neither case is it completely clear from STABLE-APIS.TXT. I'm also using "sys/atomics.h", which similarly seems to be implemented in Bionic, so based on my interpretation it should be safe.

I can do "man foo" and see if it asks me to link with something (on a Linux man page), so I can get somewhat of an idea from that. But there's also this clause in STABLE-APIS.TXT:

>The C library headers, as they are defined on Android 1.5 are available
>through their standard names (<stdlib.h>, <stdio.h>, etc...). If one header
>is not there at build time, it's because its implementation is not available
>on a 1.5 system image.

Which implies to me that some otherwise standard C library functions aren't necessarily available. Which brings me back to my original point: Is there a better way than just grepping the include files to find out if a particular function is supported? Should I run Doxygen over the include folder just to get a list of what's available? And if we're using the include tree to determine which files we can and can't use, is it all de facto safe unless it's in "linux/" or "asm/"? In particular, is "sys/" guaranteed to be safe?

Tim


__________ Information from ESET NOD32 Antivirus, version of virus signature database 5259 (20100707) __________

[David Turner]

On Tue, Jul 6, 2010 at 10:26 PM, Clayton Hughes <clayton...@gmail.com> wrote:

Tim,

$NDK/docs/STABLE-APIS.TXT isn't searchable, but it tells you exactly
what you can use and what you can't:  You get all of the standard C
library, math, and a few select tidbits of C++.

Because sockets isn't part of the C lib or otherwise mentioned in the
stable-apis, I'd be hesitant to use it.

slight correction: sockets *is* definitely part of the C library.

 

On Jul 6, 12:26 pm, Tim Mensch <tim.men...@gmail.com> wrote:
> Dmitry Moskalchuk wrote:
> > BSD sockets
>
> > See build/platforms/android-*/arch-arm/usr/include/sys/socket.h
>
> Is there a set of man pages or other searchable documentation that
> includes only exactly what is available on Android? Or is the best
> approach to just grep for commands in the include tree and look at
> standard Linux man pages when you find a command?
>
> Tim
>
> __________ Information from ESET NOD32 Antivirus, version of virus signature database 5256 (20100706) __________
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com

--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To post to this group, send email to andro...@googlegroups.com.
To unsubscribe from this group, send email to android-ndk...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.

[Andrei Hanganu]

Hello,

I can confirm that sockets work flawlessly for quite some NDK versions
now. Also if you are familiar with socket polling the NDK supports the
SELECT method in older ndks and the linux standard EPOLL system in the
r3 and r4 releases. Documentation on sockets and select and epoll you
can find in online man pages if you don't have a linux installed:

http://linux.die.net/man/7/socket - socket man pages
http://linux.die.net/man/2/select - select man pages
http://linux.die.net/man/4/epoll - epoll man pages

I am not positive epoll is part of the stable apis but I have been
using it for quite some time and never had issues, so unless in a
future version they suddenly decide to remove it, it should be safe.

Andrei

[David Turner]

epoll is part of the stable APIs, it was a header packaging problem in previous NDK releases, but all platform system images support it.

[pankaj...@gmail.com]

i have seen people using osip, exosip and rtp libraries for network communication, these are compiled with ndk. so theoretically and practically the tnework interface works very well.

[Clayton Hughes]

I'm totally with you, Tim. I've been thinking about my interpretation
of the file and I don't know if it's overly strict or not. My initial
thought was to err on the side of caution.

I assumed "C libraries" meant "only the C libraries as defined by ISO
C90." It has been a bit painful, though, to avoid using any of the
POSIX C library. Maybe they're all also okay... it'd sure be nice to
get some official clarification on this, considering how adamant
Googlers seem to be about not using non-stable APIs.

If it's not the case that anything we don't have to alter the build
setup to link against is okay, then I'd like to echo your call for an
official list of stable header files or something.

On Jul 7, 9:10 am, Tim Mensch <tim.men...@gmail.com> wrote:
> Clayton Hughes wrote:
> > $NDK/docs/STABLE-APIS.TXT isn't searchable, but it tells you exactly
> > what you can use and what you can't:  You get all of the standard C
> > library, math, and a few select tidbits of C++.
>
> > Because sockets isn't part of the C lib or otherwise mentioned in the
> > stable-apis, I'd be hesitant to use it.
>
> Hold on. This is EXACTLY why I want a definitive list of APIs that are
> stable.
>
> I know about STABLE-APIS.TXT. It does say:
>
>  > The kernel-specific headers in <linux/...> and <asm/...> are not
> considered
>  > stable at this point. Avoid including them directly because some of them
>  > are likely to change in future releases of the platform. This is
> especially
>  > true for anything related to specific hardware definitions.
>
> But we're talking about sys/socket.h. It appears to be defined in

> Bionic, so it /is/ part of the C library. In fact, the man page for