Printable View
Can any one point me to some comprehensive resource which brings out the subtle difference between these two socket types. I found these :
http://www.unet.univie.ac.at/aix/aix.../skt_types.htm,
http://www.opengroup.org/onlinepubs/...ns/socket.html
But, Its still not very clear.
I am using LINUX
The difference is two-fold:
Difference #1 - SOCK_SEQPACKET handles backpressure by tossing out the offending packet and returning an error to the sending socket, whereas SOCK_STREAM tosses out the offending packet, then asks for it to be retransmitted when the buffer has space. This makes SOCK_SEQPACKET potentially more efficient in that the sender can reduce the outgoing data rate to reduce dropped packets.
Difference #2 - SOCK_STREAM is supported by windows and all major versions of linux SOCK_SEQPACKET is only supported by a subset of fairly arcane builds of linux AFAIK.
Thanks,I still have a few questions,
by "offending packet" which one of the following do you mean:
1. The packet that arrives at a router when its receive queue is full.
2. The packet that arrives at the receiver when its receive window is full.
3. The packet whose data has been corrupted due to network interference.
Also, how much do the socket types depend on the protocol/family that I have chosen? I mean, I am not using AF_INET. I am using a protocol that supports both STREAM and SEQPACKET types. Will the behavior be any different across the two families?
The more I try to think, I only get more un-answered questions.. As I had asked in my first post, can you point me to some book/site that brings out the differences between the two?
Generally #2, but if you have a router that actively manages TCP/IP (high end router) then #1 would also apply.
#3 would depend on the nature and placement of the corruption, but in either case both SOCK_SEQPACKET and SOCK_STREAM would handle that case the same.
AFAIK, the family is irrelevant as long as it supports the connection type you want. Out of curiosity, what family are you using?
I am using AF_TIPC.
And once again , can you point me to some book/site that brings out the differences between the two?
You can check out http://tipc.sourceforge.net/doc/Programmers_Guide.txt , but from the first few paragraphs, it appears that its an experimental addressing scheme that isnt yet fully functional, so unless you are directly involved with its development (in which case you wouldnt be asking for info on it), I woudl suggest you pick a different scheme. It doesnt seem to have any advantages over IPv4 other than the fact that all NIC's in system must have the same network addres, adn it basicalyl sees them all as connections to the same logical network. So probably there is some driver level support for packet multiplexing, btu I didnt realyl read that deep into it.
If you dont mind me asking, what made you choose that AF over AF_INET?
Yeah, I have read that document. About the socket types, it only says :
TIPC currently supports the following values for "type":
a) SOCK_DGRAM - for unreliable connectionless messages
b) SOCK_RDM - for reliable connectionless messages
c) SOCK_SEQPACKET - for reliable connection-oriented messages
d) SOCK_STREAM - for reliable connection-oriented byte streams
True, I am not a TIPC developer. And about the choice between AF_TIPC and AF_INET, I am afraid I cant divulge that information. I am interning at a company and I am bound by their confidentiality laws.
I understand. I'm under a noncomp/nondis myself. The trick is to not give otu application specific data, only the particular requirement. For example, I could say I need to use function foo() because it supports feature 'bar', without saying why I need feature bar or what I intend to use foo(bar) to accomplish. If you cant disclose enough information for us to help you, then obviously we wont be able to help you.
Umm.. Well, here goes. We are trying to use TIPC instead of TCP as the lower level communication protocol for one of our products as it does offer a slightly better bandwidth and latency figures over a wider range of data-sizes. Thats about as far as i can go. Anyway, it turns out that we will be using SOCK_STREAM instead of SEQ_PACKET. But, i am still curious to know the intiricate differences between the two.
And wow!! this is my 300th post. :)
well, essentially there is no difference from an application developers point of view. The difference is in how the socket stack handles the transfer. SOCK_STREAM lets the stack know that it should send data whenever it can, while SOCK_SEQPACKET lets it know that it should wait for the application to finish the send() before creating a packet. SOCK_STREAM would perform marginally better on latency tests I imagine, while SOCK_SEQPACKET would perform marginally better on bandwidth. I cant imagine why you are getting better latency figures for SOCK_SEQPACKET except that you are sending fewer packet headers, or possibly you are going through a proxy and since the proxy doesnt 'know' if it can cache SOCK_SEQPACKET packets, it assumes it cant and immediately forwards them, whereas it checks its cache for SOCK_STREAM packets.
We plotted the bandwidth behavior of TIPC with SEQ_PACKET and STREAM for datasizes >4000 bytes upto 65K bytes and for latency we considered data sizes less than 1K to get a finer view. True, There isnt much to choose between the two as far as latency is concerned. But, for b/w , even we were surprised to see STREAM doing better than SEQPACKET. One would naturally think SEQPACKET to perform atleast at par with STREAM if not better.
I checked into this, and its probably an issue with your implementation of seqpacket.
> your implementation of seqpacket.
Are you talking about how TIPC implements seqpacket or the way I am using it in my code?