Here’s your Assignment 2 on simulating alternating-bit protocol. This is a simple assignment (the solution is only ~40 lines of code) to be completed and submitted INDIVIDUALLY before 30 March, 2014, 11:59PM. Despite the simplicity, please start early!
28 comments to Assignment 2
Leave a Reply
You must be logged in to post a comment.
Hi,
How come the file is read only! How to change it?
chmod it
I cannot find the specific file inside @cs2105-z.comp.nus.edu.sg
did you type:
cp -r ~sadm/a2 .
?
Note that you must write the fullstop
Do we need to handle the situation when the file.length is 0?
Sry, this problem is also wrong.
I wonder if others are facing the same problem with me:
EOF problem:
I try to test my program, it closes correctly but when it reaches the endline of FileSender.java it just did not end it. It keeps on running and I don’t know why.
Sry. My problem.
Problem’s solved. :)
The specification mentioned about the EOFException, but while I was doing the asg I found that if the UDTSender tries to send data to UDTReceiver(already closed) will lead to an IOException instead of EOFException. I wonder what situation will lead to an EOFException?
Zhou Wei,
I think if the program runs correctly,
UDTReceiver should not be closed by that time,
it should be closed after receiving
the 0 byte data.
EOFException happens when the receiver’s connection has
closed, but the UDTSender’s InputStream still readObject(). But since receiver is no longer sending object, so readObject will read the “end of file” so it will throw “end of file exception” (EOFException) to signify the end of the connection.
This is how I understand it, hope that I can help you! ^^
Jun Wei
Thanks for your reply.
I think I find the problem, EOFException is a subclass of IOException…
Sometimes I will encounter a case whereby when the sender sends the 0 byte data, the UDTReceiver drops the packet. In the end, both the sender and receiver waits forever…
I realised this 0 byte data sending is being implemented in the FileSender class and will not timeout to resend, thus it ends with a “waiting forever” situation.
Or in this case when we catch the EOFException at the sender side and when the UDTReceiver chooses to corrupt/drop the packet, our implementation will try and receive another packet from the socket but will be thrown EOFException again because we close the connection at the sender side.
My question is, do we catch this EOFException and assume there is no more packet to be received at the receiver side too?
Sorry, I guess we need to implement it in rdt.close()…
This is my problem. :)
Hi, I am getting a java.net.ConnectException: Connection refused errod when running the FileSender. Any help?
run your receiver first?
It’s already running.
what server are u running on?
sunfire.comp.nus.edu.sg
hmm.. should put in
cs2105-z.comp.nus.edu.sg
:)
Oh! Yeah, that seemed to work. Thanks!
Hi
The assignment requires us to handle the EOFException occurred at the end of the transfer, by modifying the close() method in RDTSender.java.
I have nothing against this requirement, but just curious: if I close the connection at the sender side without even notifying the receiver, hence handle the EOFException in RDTReceiver.java instead, do I get penalized?
Because, technically the two methods are equally effective; in fact the second version is more efficient.
Sorry I don’t think my question makes sense any more.
Please ignore this.
Sorry.
I think my question still stands.
Any answer will be helpful.
Thanks.
When do you think the sender should close the connection?
As long as you can transfer the last packet reliably to the receiver, you won’t be penalized.
My idea is that, the sender can close the connection immediately after it receives the uncorrupted ACK in response to its last sent data packet. At the same time, and EOFException will be thrown at the receiver since the connection has closed, that’s when the receiver can break out the loop and stop receiving, hence proceed to close its own socket.
However I realized it’s only more efficient in this virtual context as the java application is running on top of a reliable protocol underneath. It won’t be reliable if we are to implement everything from scratch.
Therefore I will stick to the original idea whereby the receiver should close the connection upon receiving an empty packet before the sender catches the EOFException.
Thank you.
I transferred the file out of ssh to edit. However when I want to transfer it back to ssh, it gives me an error message “Permission denied”. Also it appears that if I edit the code in ssh, I cannot save it. What can I do? Thanks
$ chmod 600 *.java
this should fix the file permission.