Hello Marcelo, Your problem has nothing to do with AMD processors. It was by coincidence that the machine that produced the problem had an AMD processor. You should try an Intel one also. As far as I know, socket implementations doesn't depend on or differ by processor type. They should not. When you track down a problem, first always try to find the cause in YOUR work, among the things that YOU did. People (including myself) are feeble and tend to forget this. The more experience one has, the higher the probability is, to forget the above. Colleagues, NEVER forget it !
I wish good luck for everyone ! Cheers, Peter On Fri, 09 Jun 2006 22:58:14 +0200, Marcelo Grossi <[EMAIL PROTECTED]> wrote: > Hello again folks, > > I managed to "fix" the bug I told you guys about. Aparently it is endeed > an ICS related problem or AMD's fault, can't be concise on that. Here's an > overview of the problem with the solution in sample codes: > > Problem: The server did not received the packet from the client, only > the first one. The packets in question were being sent from inside a for > loop (small one, about 50 iterations). Here is a sample code of the "faulty" > version of the code (Delphi 6): > > for I := 0 to Count-1 do > begin > // This line being the assembly of the buffer, > // it is a very clean code and is a very fast function and very few > data. > // Buffer size estimations are about 20- bytes. > BuildMessage(aString, aBuffer); > // sends rapid-fire buffers to the server > Socket.Send(@aBuffer[0], Length(arBuffer)); > end; > > Solution: Using the cumulative send function provided with ICS the > problem is strangely resolved and the server receves ok the buffers (in this > case, the single buffer made of the small buffers). Here is the sample code: > > for I := 0 to Count-1 do > begin > // Same buffer assemblage > BuildMessage(aString, aBuffer); > // Only sends the packet when the processing is finished (last > iteration) > if I = (Count - 1) then > Socket.Send(@aBuffer[0], Length(aBuffer)) > else > Socket.PutDataInSendBuffer(@aBuffer[0], Length(aBuffer)); > end; > > I hope I could be of any help and I'm pretty sure this can be reproduced > (using the sample codes above) in any client/server model being the client > an AMD 64-Bit processor (can't say much about Intel 64-Bit processors > because we could not test it out). Anyways, thank you very much for all your > responses! > > Best regards, > > Marcelo Grossi > > ----- Original Message ----- > From: "Arno Garrels" <[EMAIL PROTECTED]> > To: "ICS support mailing" <twsocket@elists.org> > Sent: Friday, June 09, 2006 8:24 AM > Subject: Re: [twsocket] 64-Bit Processors Issue > > >> Marcelo Grossi wrote: >>> Hello again, >>> >>> I'm new to this list and since I've been getting your messages, I >>> was wondering if anyone got the message I sent about the problem I'm >>> having with the 64-Bit AMD processors. I really really need your help >>> on this, because I've never altered the source code of ICS and the >>> problem mentioned (see below) only happens with users of 64-bit AMD >>> (never tested with Intel) processors. >> >> It is very very unlikely that ICS in combination with AMD64 is the >> reason. I personally had troubles with hardware DEP (nx-flag) caused >> by another third party component, however I got at least a very strange >> exception. >> >> --- >> Arno Garrels [TeamICS] >> http://www.overbyte.be/eng/overbyte/teamics.html >> >> -- >> To unsubscribe or change your settings for TWSocket mailing list >> please goto http://www.elists.org/mailman/listinfo/twsocket >> Visit our website at http://www.overbyte.be >> > -- FIGYELEM ! Ennek a levélnek a végén NINCS REKLÁM !!! észrevetted ? -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
