Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations IamaSherpa on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

tcp/ip write in tight loop

Status
Not open for further replies.

hank8001

Technical User
Oct 2, 2011
2
US
So here's my problem - I'm writing a simple client/server application that uses TCP/IP between two separate tasks running on different processors. The sender is running on VxWorks 5.4, which is where the problem is occurring. I have a loop where I'm sending six small messages (less than 32 bytes) in a tight loop (six calls to "write" within a loop). If just the "write" is in the loop some of these messages are lost, and never make it to the receiver. However, if I put in some printf statements or just a taskdelay into the loop, then the messages are delivered with no problem.

Anybody have a clue as to what is going on? I could live with the taskdelay in there, but it seems awful kludgy. Is there maybe some sort of TCP option that needs to be set to allow this to work? My guess would be that this is some sort of quirk in the quirky VxWorks TCP stack...
 
Been 35+ years since i worked on something like this and it was not tcp/ip. At that time, you did not "send" thing 2 until the receiver was ready (actually, the receiver was checked before the first send).

I suspect you are over-running the receiver.

Do these need to be 6 separate messages or could the loop build multiple entries in one messsage and then send them all as one?
 
Thanks for the response, but no, that is not the problem. I'm not sending anything until a connection is established, so it is not a matter of sending something before the receiver is ready. Messages sent before the six message burst get through just fine, and then some but not all of the messages in the six message burst get through. I seriously doubt it is a problem in the receiver because (a) TCP is designed to preserve ordering in message delivery, so it would keep trying the first nondelivered message with a overwhelmed receiver, rather than skipping some of the messages, and (b) things work the same when I run the receiver on two different platforms (VxWorks, Linux).

My design is flexible enough that I could bundle the information into one message, but before I consider my options I would like to see if anybody has some insight into what is going on...
 
Hopefully, someone who has written something similar with tcp/ip will join in. . .

However, i still believe it is possible that even though a connection has been established, it is still possible to "overrun" the receiver. Assuming that the tcp/ip protocol works quite similarly across platforms, i would expect the same problem(s) / successes.

Good luck!
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top