|
You haven't even said what the problem is.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Yeah, sorry about that.
While I am trying to transfer the data, it is stuck at some point. The server doesn't make any other requests and hence, the client doesn't send any more data.
I have no idea why nothing new happens.
|
|
|
|
|
Well, there is no way to tell why that happens just from the info you have provided.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Run the server in the debugger, and be sure that the size of the file is communicated properly.
Maybe the server thinks the file is smaller than it really is, and so it stops asking for more data.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
I am aware that the information with which I've provided you is less than sufficient, but it is really hard for me to isolate the code that works on the transfer, and there is a chance that isolating it from the rest of the application will leave you with no problem to solve. The problem may as well be stemming from the structure of the rest of the application.
I will check if there is a problem with the file size tomorrow, but I don't think that is the problem. When I occasionally place a breakpoint and break the program, it manages to transfer a little bit more data (around 300KB more).
|
|
|
|
|
You have no mechanism in your protocol to force either the client or server to force another request for the same data. If, after a timeout expires, the client doesn't get an ACK from the server, it should be able to try and reestablish communication, telling the server it's going to resend a block of data.
|
|
|
|
|
Thank you. Why haven't I thought of that. 
I will add that mechanism first thing tomorrow. By the way, even though this will probably solve my problem; there must still be a problem in my system since it is really unlikely for a package to be lost on a local TCP connection.
|
|
|
|
|
TCP guarantees that the sent packets will arrive, unless the connection drops entirely (which the OP would have noticed), so I doubt that this is the problem.
|
|
|
|
|
The connection is still intact, it doesn't drop. The only problem is that the server stops requesting chunks.
|
|
|
|
|
I know. It works great too, on paper. In actual practice, it's not 100% accurate.
|
|
|
|
|
Some possibilities
- Ignored exceptions on server
- Buffer doesn't match size (read/write). Either end.
- Something is pausing the server.
Seems that the problem is deterministic so you can add logging and print exactly what the sizes are that you read and write each time.
|
|
|
|
|
what you should do IMO is this:
1.
improve observability: provide logging on both sides, with actual times, and relevant data, such as offset and length.
2.
create a synthetic test file, so the receiver can predict and hence verify what should and is received. Here is one useful algorithm: for each block, start with the offset (yes, I mean stuff the offset in the data, I know you already send it as metadata), then add incrementing data modulo some number that isn't a power of 2 (for bytes, 255 works just fine). The net result is (1) each block is different (the offset!), and (2) yet very predictable. You'll see immediately if and when what gets received is completely wacked.
3.
As you have packets already in your yet extremely simple protocol, add a checksum to the protocol, so the receiver can verify things are correct. And send an ACK (when OK) or a RESEND-REQUEST (when checksum fails or something goes wrong).
4.
Refinement: don't wait for the ACK before you send the next packet; a strictly sequential process would slow things down needlessly (sender calculates checksum, sends data, waits for ACK, receiver gets data, checks checksum, sends ACK/RESEND, resulting in two periods the line isn't active at all). Instead, allow for at least 1, better a few, packets in progress, i.e. only wait for ACK for packet 1 after having send packet 1+N where N is 1 upto a few.
Luc Pattyn [My Articles] Nil Volentibus Arduum
The quality and detail of your question reflects on the effectiveness of the help you are likely to get. Please use <PRE> tags for code snippets, they improve readability. CP Vanity has been updated to V2.3
|
|
|
|
|
Since it works for small files, and appears to be deterministic (does it always fail at the same point? or is it just more likely that larger files will fail?), it must be to do with filling an array, running out of space in a TCP buffer or something similar. If it is not so simple (i.e. it fails more on larger files, but it is not deterministic) then it is probably to do with the handshake to request more data.
It is impossible to go into any more detail than that with the information available. I can only echo the advice to sprinkle your code liberally with logging statements to find out what is actually happening.
Why are you doing that, anyway? TCP guarantees the ordering and transmission so you can just send the whole file on the sender end. What you are doing adds latency (2 way ping) each chunk.
|
|
|
|
|
I can't say that it is deterministic since if I pause the program at certain intervals, it can complete the transmission. If I don't pause the program at all, it stops after transferring 200-300KB.
I am aware that what I am doing is just slowing down the transfer rate, but I am new to this are of programming and currently trying to develop this project to increase my experience.
I will now add a timeout system to the server and request the rest of the data if nothing is incoming.
|
|
|
|
|
SimpleData wrote: I can't say that it is deterministic since if I pause the program at certain
intervals, it can complete the transmission. If I don't pause the program at
all, it stops after transferring 200-300KB.
As another thought - a firewall.
It is throttling your throughput. When you pause it you are throttling yourself so it doesn't get involved.
The same behavior could be due to some oddity in your server code though. Such as attempting to be clever by using threads for reading and writing.
|
|
|
|
|
Can you elaborate on "attempting to be clever by using threads for reading and writing"? Because it sounds like something I might have done.
|
|
|
|
|
To use two threads something needs to control access to the shared data.
If you mess that control up then you can end up blocking or taking a large amount of time.
|
|
|
|
|
Wouldn't using the "lock" directive be enough?
|
|
|
|
|
No idea what you are referring to.
If you are asking if you can block using lock then yes.
|
|
|
|
|
I got killed in an interview recently because in my adhoc programming, there are certain things I have never had to deal with. I am a competent programmer and it was pretty discouraging to take such a brow beating, but it is what it is. I learn as I need to, and while that has kept me employed and producing, it obviously is not preparing me to move forward. Can someone give me direction as to some e-courses that will help me to refine my skills? Especially as it pertains to memory management, multithreading, etc...
I enjoy tutorials and sample code, but I think that I might benefit more, at this point, from classic structured detail oriented teaching.
Cheers, --EA
|
|
|
|
|
IMO, if you want a structured approach, teaching you "all" about some language or technology, you should choose, buy and study (front to back) a book. The free, virtual and intangible courses just don't offer the same quality and consistency. And then you can add by reading anything you like, including e-books and CP articles; and of course practice some more.
Luc Pattyn [My Articles] Nil Volentibus Arduum
The quality and detail of your question reflects on the effectiveness of the help you are likely to get. Please use <PRE> tags for code snippets, they improve readability. CP Vanity has been updated to V2.3
|
|
|
|
|
I'm going to go the other route and give you the TRUE REALITY on these types of interviews. DON'T SWEAT IT.
1) Interviewers are generally very cocky / arrogant during the interview. Why not? Your fate is in their hands. Now some interviewers take pride in being complete douche bags during the interview. I've run across MANY of these types in my 17+ yrs. Basically, they spent the last couple of weeks doing something really obscure that they are super proud of and they think they are "da bomb" because of that and think you are a looser if you don't have that same obscure knowledge.
2) Did you take a brow beating on "common knowledge" type stuff? Or were they peppering you with obscure questions you would run across 1% of the time? I.e. I could ask a guy I'm interviewing to go up on the white board and write out the code for a LINQ expression tree that returns the private property of a base class. Thats a douche bag question. Nobody would know that. If you get those types of questions, write the interview off as the guy not really wanting to hire anybody for his own personal reasons. If I asked a guy to describe the differences between a Grid, StackPanel, ViewBox, etc. and he didn't know that, thats kind of different.
3) Some guys ask you real world questions to get a guage of your real world knowledge while other guys will ask you mostly advanced / unpractical things just to try to get under your skin and see if you buckle under pressure. I had a friend whose interview style was exactly this. He would do his best to get you to curl up in a fetal position in the corner and start sucking your thumb and crying for mommy... he did that because a) he was arrogant b) he was a douche c) he wanted to see if you would come into work with an assault rifle if things got stressful d) he was a douche
I don't want it to sound like I'm bitter because I got turned down for a few jobs, this is just reality of how interviews go.
Heck, I have a co-worker at my current company that throws out anybody who can't recite RegEx off the top of their head in an interview.
I couldn't recite ANY RegEx off the top of my head. Who cares? I can go to www.regex.com and c&p a regular expression from there. If its a custom regex I need, well, I'm sure I can figure it out.
|
|
|
|
|
Thank you for the feedback, I have been pretty down this morning about the whole situation. The questions were not obscure, they were just outside the scope of my experience. I have been writing code ad hoc by myself for ten years, so the code works and that is the end of it. The questions were reasonably simple I think, just outside of my scope.
Typical stuff:
Access modifiers
Multi Threading
Value Types vs. Reference Types
Linq Questions
Inheritance
These are not terribly obscure things, I think they are fairly standard. The thing is that I have never had to use some of the things they wanted. Example: Access modifiers, I have never used internal, pretty much only public and private. Multi threading, I have always used the background worker as opposed to creating a thread by hand because that is the first example I found when I was looking. I have never had to use a ByVal vs a ByRef, and I have never used an abstract class, only interfaces.
So really it is an experience issue. I felt absolutely stupid as I sat answering questions from seven different people.
Now, let me say that this was possibly the nicest group of programmers I have ever sat down with, they were all extremely sympathetic about the whole situation. It just sucks to realize that what you know is a grain of sand and what you don't is an entire beach.
With that said, I want to make sure going foward that I can hit the interview questions since interviews never seem to figure out if you can code or not.
Cheers, --EA
|
|
|
|
|
Ok...
1) Yeah, access modifiers are considered "common knowledge". Public / private are the most common. Protected is pretty common too. Internal is useful in WPF (since you sometimes want to make stuff private and that won't work with data binding on occasions)... protected internal, well, IMHO, that’s *generally* used in code hacks.
2) Multi-threading - if you knew BackgroundWorker and thread synchronization techniques, I'd say that’s pretty good. Async CTP is another good thing to pick up. You might need to create threads by hand if you want to spin off say 10 background threads. You should probably know the differences between mutexes, semaphores and critical sections as that’s a basic interview question.
3) value vs. reference type, yeah, I guess you should know that.
4) LINQ... meh... that’s an obscure question IMHO... if you see code that uses LINQ everywhere, chances are they are constantly battling performance issues.
5) yeah, you should know inheritance so you are not c&p'ing code all the time.
|
|
|
|
|
Thanks for the insight, any other common things come to mind?
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
