I managed to reproduce a situation that might be similar to yours. I think, ironically enough, your recipient is consuming the data faster than you're writing it.
I managed to reproduce a situation that might be similar to yours. I think, ironically enough, your recipient is consuming the data faster than you're writing it. Import java.io.
InputStream; import java.net" rel="nofollow">java.net. ServerSocket; import java.net" rel="nofollow">java.net. Socket; public class MyServer { public static void main(String args) throws Exception { final ServerSocket ss = new ServerSocket(12345); final Socket cs = ss.accept(); System.out.
Println("Accepted connection"); final InputStream in = cs.getInputStream(); final byte tmp = new byte64 * 1024; while (in. Read(tmp)! = -1); Thread.
Sleep(100000); } } import java.net" rel="nofollow">java.net. InetSocketAddress; import java.nio. ByteBuffer; import java.nio.channels.
SocketChannel; public class MyNioClient { public static void main(String args) throws Exception { final SocketChannel s = SocketChannel.open(); s. ConfigureBlocking(false); s. Connect(new InetSocketAddress("localhost", 12345)); s.finishConnect(); final ByteBuffer buf = ByteBuffer.
Allocate(128 * 1024); for (int I = 0; I Position(0); } Thread. Sleep(100000); } } If you run the above server and then make the above client attempt to write 10 chunks of 128 kB of data, you'll see that every write operation writes the whole buffer without blocking. However, if you modify the above server not to read anything from the connection, you'll see that only the first write operation on the client will write 128 kB, whereas all subsequent writes will return 0.
Output when the server is reading from the connection: to write: 131072, written: 131072 to write: 131072, written: 131072 to write: 131072, written: 131072 ... Output when the server is not reading from the connection: to write: 131072, written: 131072 to write: 131072, written: 0 to write: 131072, written: 0 ...
I've been working with UDP in Java and have seen some really "interesting" and completely undocumented behavior in the Java NIO stuff in general. The best way to determine what is happening is to look at the source which comes with Java. I also would wager rather highly that you might find a better implementation of what you're looking for in any other JVM implementation, such as IBM's, but I can't guarantee that without look at them myself.
I'll make a big leap of faith and assume that the underlying network provider for Java is the same as for C...the O/S allocates more than just SO_SNDBUF for every socket. I bet if you put your send code in a for(1,100000) loop, you would eventually get a write that succeeds with a value smaller than requested.
Thanks for the idea. I just did a few hundred multi-megabyte writes and not a single one of them returned with a value less than the full amount. – jpdaigle Oct 1 '08 at 15:23 Any chance you can watch the traffic with a sniffer and see how the packets are being sent?
Might give you a clue if the sending library is even trying to break up the packets into smaller than MTU chunks. – stu Oct 1 '08 at 21:55.
You really should look at an NIO framework like MINA or Grizzly. I've used MINA with great success in an enterprise chat server. It is also used in the Openfire chat server.
Grizzly is used in Sun's JavaEE implementation.
Keep in mind that the network acts as a buffer that is at least equal in size to your SO_SNDBUF plus the receiver's SO_RCVBUF. Add this to the reading activity by the receiver as mentioned by Alexander and you can get a lot of data soaked up.
Well yes but in TCP there can't be any data in flight that isn't also in the send buffer. – EJP Nov 10 at 22:19.
I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.