Question

This week, I messed around with Chromium’s Socket API a bit. But there’s something which isn’t really clear to me about this bad documented experimental interface.

What The docs on Google Code Say:

… about sendTo() at the moment:

Writes data on the given socket.

1. socketId ( integer ) The socketId.

2. data ( ArrayBuffer ) The data to
   write.

3. address ( string )
   The address of the remote machine.

4. port (
integer ) The port of the remote machine.

5. SendToCallback ( function
)

But the description of sendTo() is exactly the same as the description of write() (write – Writes data on the given socket.). It’s the same about recvFrom() and read() – both of them have got exactly the same description (read – Reads data from the given socket. / recvFrom – Reads data from the given socket.). But nobody says interesting anything about the differences.

What I Found Out:

It doesn’t matter what I’m doing, sendTo always returns the following object:

• [-] Object
  • bytesWritten: -2
  • [+] __proto__: Object

If I use write instead of sendTo in all these situations, everything happens as expected.

It’s the same with recvFrom() and read() – read() is working as expected and recvFrom() fails.

My Question(s):

• What is sendTo() for and what’s the difference between write()
  and sendTo()?
• What is recvFrom() for and what’s the difference between read() and recvFrom()?
• Why are there so many akin methods?
• And: Is there anywhere some more information about the Socket API? The Google Code docs are really lightweight. Aren’t there any articles on chromium.org concerning that?

Thanks.

Answer 1

Apologies for the confusion. We are rolling out an improvement to the documentation based on your question.

The Chrome socket API is a thin layer over a subset of the POSIX sockets API. It follows the convention that read()/write() are for connected sockets, and sendto()/recvfrom() are for non-connected sockets. At the risk of oversimplifying, you’ll want to use the former for connected-oriented protocols (TCP), and the latter for connectionless protocols (UDP). There’s a good comparison of why one would choose TCP vs. UDP in the Wikipedia article on UDP.