As the title states, what are the duplex of the BSD sockets, full? - and that is on the same single socket.
If you read the socket(2) manual page, you will see that SOCK_STREAM type sockets are full-duplex. Same for Windows, see http://msdn.microsoft.com/en-us/library/ms740506(v=vs.85).aspx .
Related
I was surprised by the connect() function for UDP. I read online and realized that it enables the send() function which does not require a destination address.
I would like to know what exactly does a UDP connect do in the kernel.
I found a similar question here
UDP "Connect"-Speed in C#
but maybe some detail was left out in the answer
There is nothing real fancy with connected udp sockets. It just means that socket name will include destination address, and as such, kernel will use this name when destination address is not provided. No more than typing shortcut for all intents and purposes.
Is it valid to use SO_LINGER with a udp socket?
If yes, would you please describe the situation or illustrative-example where SO_LINGER would be appropriate with a udp socket?
a little background:
I have never used the SO_LINGER option so I am unfamiliar with what it does or when it is appropriate to use (especially with a udp socket).
more specific context for this question:
I ask because I ran across some open source code that was implementing a udp socket and using the SO_LINGER socket option (from my 30 seconds of looking at the code it looks like a pretty standard udp socket receive and then pushing the data out to some sort of consumer via gnuradio's API).
From the short reading I have done on SO_LINGER on man pages and webpages all the pages have talked about SO_LINGER being used with connection oriented protocols (i.e. tcp, et al.)... but this code is doing a non-connection oriented protocol, udp in this specific case, so I am confused why the SO_LINGER is being used with a udp socket.
When used with a positive read timeout, it causes close() to block for up to that timeout while the socket send buffer still has unsent data in it, and any difficulty writing that data will be returned as an error from the close() method. This applies equally well to UDP as to TCP. It is little used.
The other use of SO_LINGER, with a zero timeout, applies only to TCP.
I'm sending udp packets from a device to my pc.
Proof: (click here to enlarge)
I'm using the standard "UDP Receiver VI" from LabVIEW (labview\examples\comm\UDP.llb)
But the data I sent is not displaying on the vi, even though you can see that I'm sending the UDP packet.
Please help
Labview program:
(enlarge)
Without any LabVIEW code it's hard to see what's going wrong.
Here's a working exapmle of a sender and receiver in one VI:
Could it be that you have multiple ethernet ports on your system?
Perhaps is setting the net address on the UDP open connection an option.
You have spotted the port on the front panel (64100) is not the same as the port you are sending data to (64000) ?
Can someone explain what socket(AF_INET, SOCK_STREAM, 0) actually does when you bind it to an interface?
I have a socket like this listening on an interface, and, for example, if I do a http GET from my browser, when I do a read() on the socket, I literally see the buffer starts at the "GET /HTTP..." data that is the same data that shows up in the HTTP protocol packet of my wireshark capture of the same thing. How come I don't see the TCP SYN, SYN/ACK, ACK packets as the start of the buffer?
I thought having this socket on an interface would show me literally everything, but it seems like it only shows the data, not the metadata around it.
It's a SOCK_STREAM socket. It provides a byte-stream between two applications. You never see packets on a byte-stream socket, only a stream of bytes. That the stream of bytes takes place by an exchange of packets is an implementation detail that is made invisible to the application. (And might even be bypassed if both endpoints are on the same machine.)
As the title says, How I can work with tcp sockets in kernel space?
Is there any tricky notes?
Look at ng_ksocket. Even if you will not use netgraph, it is a nice implementation of kernel-level socket manipulation.
I found a post on linuxjournal.com about networking in kernel.
May be helpful.