1. Home
  2. Field-Programmable Gate Arrays
  3. XilNet server data streaming problem from PPC

XilNet server data streaming problem from PPC

Hi

On a Virtex-II Pro I'm attempting to write a very simple TCP/IP server application running on the PPC. The goal is that when a client connects to the server it will wait until the correct command from the client tells it to send data, so far successful. The problem is that I want the server to send data streaming until the client tells it to stop, and for some reason the client won't send the correct ACK to any data packet but the first one. The acknumber is not updated correctly. I suspect that I am doing something wrong in my server application. I am able to send consecutive data packets if (and only if) every packet is acknowledged by manually sending a packet from the client.

The server only accepts one client at the time, and the connection is kept alive until the client disconnects it (Yes, I have added that feature to the TCP state machine of the XilNet library).

Does anyone have similar experience with the XilNet lib? Is it possible to send streaming data using it?

I will send the source code to anyone interested in giving it a quick look.

--
-----------------------------------------------
Johan Bernspång, xjohbex@xfoix.se
Research engineer

Swedish Defence Research Agency - FOI
Division of Command & Control Systems
Department of Electronic Warfare Systems

www.foi.se

Please remove the x's in the email address if
replying to me personally.
-----------------------------------------------
Reply to
Johan Bernspång
Loading thread data ...

Without knowing the particular package you use, but having written a fullblown tcp/ip implementation for PPC, I would say that either your client is messed up (does not send the right ack segments so you have to manually send them) or, more likely, some of the segments the server sends after the first one get lost and thus the client never sends an ACK. If the IP layer is doing fragmentation/defragmentation, this could be a place to look at. Also, I have encountered similar behaviour when I have had simply physical layer problems (too many lost packets), but in most cases the TCP retransmission would take care of that. Hope this is of some help...

Dimiter

------------------------------------------------------ Dimiter Popoff Transgalactic Instruments

formatting link

------------------------------------------------------

Reply to
dp

Hi Dimiter and thanks for your input,

The client is made in .NET by a colleague, and I don't think that the socket package is behaving badly. I have also tried to connect with a terminal program to my server as well with the same results.

I have been sniffing the communication with Etherreal and what happens is that the server starts listening on a certain port (i.e. accept is polled until a client connects). The initial SYN and ACKs are carried out correctly and the server is waiting for the client to send it some sort of commando. This is done in the same loop as accept on the established connection. When the client tells the server to start sending data a xilsock_send command is added to the loop. That is, each looping does first an accept to check for packets, second a parsing of the available data (if any), and finally a sending of data. In Etherreal I have seen that the first data packet is sent successfully followed by an ACK from the client, the second data packet is sent too (with the correct seqno and ackno), but the ACK to that data packet is a duplicate of the first ACK (thus with the wrong ackno). The server then tries to retransmit the failing packet without success... I wouldn't be surprised if my server application is lacking some feature, but I really can't see what it is.

Johan (from the living room couch on a Friday night)

--
-----------------------------------------------
Johan Bernspång, xjohbex@xfoix.se
Research engineer

Swedish Defence Research Agency - FOI
Division of Command & Control Systems
Department of Electronic Warfare Systems

www.foi.se

Please remove the x's in the email address if
replying to me personally.
-----------------------------------------------
Reply to
Johan Bernspang

Hi Johan,

this really sounds like the segment you call "second packet" is either bad when being sent or lost at the receiving side, thus the server retransmits. Since it does have the right seq and ack numbers, the reason must be elsewhere - could be the tcp checksum, IP header checksum, some other bad field, damaged IP, misrouted, you name it. Please feel free to contact me priavately if you feel like it, I'd be happy to look into the IP packet exchange (but I do think it will just take you another hour or so of thorough inspection and you'll figure it out, these things are bulky yet pretty straight forward).

Dimiter

------------------------------------------------------ Dimiter Popoff Transgalactic Instruments

formatting link

------------------------------------------------------

Reply to
dp

Hi

Yeah had the same problem with that library. I dont think they have any interest in fixing it either. So I use lwip now. That had bugs too, Xilinx bugs, but they have sorted it out now.

--

---------------------------------------------- Posted with NewsLeecher v3.5 Beta 2 * Binary Usenet Leeching Made Easy *

formatting link

----------------------------------------------

Reply to
Anonymous

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.