I think there are 2 problems here.
The first one seems to be a bug in TcpipServerChannel (the SSH protocol has
a windowing mechanism to avoid flooding one side and this is not handled
properly in that class).
It's a one-line fix though, so if you want to test it, you simply need to
add
localWindow.consumeAndCheck(len);
into TcpipServerChannel#doWriteData
I've raised SSHD-321 for the above issue.
However, i think there is a second problem in your code. Due to the above
windowing mechanism, and given your server simply echoes back, the server
itself may be stuck waiting for some space. That's because your client
side does not consume the input stream until after having written all the
data. So that needs to be changed in some way in your code.
Cheers,
Guillaume Nodet
2014-05-12 8:25 GMT+02:00 Maheedhar <[email protected]>:
> server.java <
> http://apache-mina.10907.n7.nabble.com/file/n42155/server.java>
>
> The above file is the server code
>
> client.java <
> http://apache-mina.10907.n7.nabble.com/file/n42155/client.java>
>
> This is the client code
>
> I sent a large amount of bytes, by reading a jpeg image at the client side
> and I sent the bytes through to the server. At the server side, When I
> debugged, I could see that all the bytes are received in the
> messageReceived() method of the NioSocketAcceptor instance named acceptor
> in
> line 68 of ther server code. But once the bytes are sent from there , I did
> not receive them again at the client side
>
> Note that before sending such a large amount of bytes, I have sent small
> number of bytes in the line channel.getOut().write("Hello".getBytes());
> from
> the client, which is properly received at the server side and again
> forwarded to the client side
>
> Only when I send such a huge load , I am not receiving any bytes back at
> the
> client side
>
>
>
>
>
>
> --
> View this message in context:
> http://apache-mina.10907.n7.nabble.com/Load-issue-in-apache-SSHD-when-using-ChannelDirectTcpip-tp42155.html
> Sent from the Apache MINA User Forum mailing list archive at Nabble.com.
>
