XilNet server data streaming problem from PPC

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

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

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)

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

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

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 *

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