Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Начинающим";
Текущий архив: 2007.08.26;
Скачать: [xml.tar.bz2];

Вниз

Запись буфера помогите?   Найти похожие ветки 

 
r.o.o.t ©   (2007-07-29 12:39) [0]

Как записать мне то что хранится в buf в переменную Reply:WideString?

LengthA:=Socket.ReceiveLength;
   GetMem(Buf,LengthA);
   Socket.ReceiveBuf(Buf^,LengthA);
    write(Reply,buf^);Тут надо записать как?
   FreeMem(buf);


 
Юрий Зотов ©   (2007-07-29 13:34) [1]

Move


 
SlymRO ©   (2007-07-30 04:30) [2]

а если нечетное колво байт? Wide это 2байта на символ :)


 
Сергей М. ©   (2007-07-30 09:16) [3]


> r.o.o.t ©   (29.07.07 12:39)


Сначала с чтением разберись.

ReceiveBuf - функциональный метод. Значение, возвращаемое им, не обязано быть равным LengthA.


 
SlymRO ©   (2007-07-30 10:02) [4]

Сергей М. ©   (30.07.07 9:16) [3]
В данном случае будет равно LengthA, т.к. ReceiveLength ворачивает доступное к чтению без блокировки


 
Сергей М. ©   (2007-07-30 10:11) [5]


> SlymRO ©   (30.07.07 10:02) [4]


Note: ReceiveLength is not guaranteed to be accurate for streaming socket connections


 
Сергей М. ©   (2007-07-30 10:17) [6]

Цитата из Winsock API Reference (ioctlsocket):

If s is stream oriented (for example, type SOCK_STREAM), FIONREAD returns an amount of data which can be read in a single recv; this may or may not be the same as the total amount of data queued on the socket


 
Evgeny V ©   (2007-07-30 14:03) [7]


> SlymRO ©   (30.07.07 10:02) [4]

Да вы правы,
> будет равно LengthA

, если по какой-либо причине например не возникнет ошибка. Проверить бы не мешало, не трудно ведь:-))


 
Сергей М. ©   (2007-07-30 14:06) [8]


> Evgeny V ©   (30.07.07 14:03) [7]


Не надо врать самому себе.
Бо нечтение (или нежелание чтения) док-ции откровенным дилетантством отдает.

Сколько queued, столько и вернет.


 
R.O.O.T ©   (2007-07-30 14:18) [9]

LengthA:=Socket.ReceiveLength;
   GetMem(bufA,LengthA);
   Socket.ReceiveBuf(bufA, LengthA);

   src := TFileStream.Create("C:\myfile.tmp",fmCreate);
   src.Seek(0,soFromEnd);
   src.WriteBuffer(bufA,LengthA);
   src.Free;

   FreeMem(bufA);

почему FreeMem(bufA) происходит с ошибкой в библиотеке oleout32.dll?


 
Сергей М. ©   (2007-07-30 14:21) [10]

Кто о че м, а лысый все о расческе)


 
Evgeny V ©   (2007-07-30 14:25) [11]


> Сергей М. ©   (30.07.07 14:06) [8]


Не понял где врать?
Если не будет ошибки ( -1 в этом случае), то ReceiveBuf  вернет, столько, сколько он запросил, а запросил он то, что уже гарантированно лежит в буфере. Потому как он это число получил заранее. Меньше уже не вернет(опять таки если не будет ошибки, о чем писал). Больше тоже, хотя на момент чтения в буфере уже может быть больше, чем когда он получил LengthA.  Если вы думаетет по другому - обоснуйте, а так я пока вижу цитирование хелпа, причем не совсем подходящего к конкретному случаю. Если бы он просто запросил какое-то число на чтение, не проверив сколько доступно для чтения, то вы были бы правы.


 
Evgeny V ©   (2007-07-30 14:42) [12]


> Evgeny V ©   (30.07.07 14:25) [11]
> Если бы он просто запросил какое-то число на чтение, не
> проверив сколько доступно для чтения, то вы были бы правы.
>

Причем отчасти правы, больше чем указан размер буфера все равно не вернет, ваше  
> Сколько queued, столько и вернет.
не верно.


 
Сергей М. ©   (2007-07-30 14:42) [13]


> гарантированно лежит в буфере


Да щщщас !

Что такое "queued" понимаешь ? Или для тебя это пустое слово ?


> вижу цитирование хелпа, причем не совсем подходящего к конкретному
> случаю


Подходит. Причем стопроцентно.

Более того - вызов ReceiveLength нафих не нужен, если в соотвесьтствии с ПИО на данном шаге ожидается к приему не более N байт.

Вот сколько receive-метод вернул из этих запрошенных тобой к приему N байт - стольким и довольствуйся - более во вх.буфере на этот момент нет физически, хоть даже и показал тебе ReceiveLength в десять раз больше)


 
Сергей М. ©   (2007-07-30 14:44) [14]


> > Сколько queued, столько и вернет.
> не верно.
>


Вернет он ЭТО:

Min("запрошено", "физически доступно в очереди чтения")


 
Сергей М. ©   (2007-07-30 14:50) [15]

Для особо бестолковых иллюстрирую сказанное в коде:

  BytesExpected := Socket.ReceiveLength;
  GetMem(Buf, BytesExpected);
  try
    BytesReceived := Socket.ReceiveBuf(Buf^, BytesExpected);
    if BytesReceived > 0 then
      SomeStream.WriteBuffer(buf^, BytesReceived);
  finally
    FreeMem(Buf);
  end;


 
Evgeny V ©   (2007-07-30 15:38) [16]

unit Unit1;

interface

uses
 Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
 Dialogs, StdCtrls, ScktComp;

type
 TForm1 = class(TForm)
   CS1: TClientSocket;
   SS1: TServerSocket;
   Button1: TButton;
   procedure Button1Click(Sender: TObject);
   procedure CS1Connect(Sender: TObject; Socket: TCustomWinSocket);
   procedure SS1ClientRead(Sender: TObject; Socket: TCustomWinSocket);
 private
   { Private declarations }
 public
   { Public declarations }
 end;

var
 Form1: TForm1;

implementation

{$R *.dfm}

procedure TForm1.Button1Click(Sender: TObject);
var
b:array [0..100] of byte;
i:integer;
begin
 for i:=0 to 100 do
  b[i]:=byte(i);
 CS1.Socket.SendBuf(b,100);
 Sleep(1000);// жду когда приедет побольше
end;

procedure TForm1.CS1Connect(Sender: TObject; Socket: TCustomWinSocket);
begin
ShowMessage("Connect");
end;

procedure TForm1.SS1ClientRead(Sender: TObject; Socket: TCustomWinSocket);
var
b:array [0..100] of byte;
k,i:integer;
begin

  k:=Socket.ReceiveLength;
 
>  i:=Socket.ReceiveBuf(b,5);


end;

end.

дельфи 6 TclientSocket (CS11) и TServerSocket (SS1), для упрощения в дизайне обоим поставил Active:=true использовал адрес 127,0,0,1 порты подберите сами, оптимизация выключена. Поставте тольковый вы наш точку останова на
i:=Socket.ReceiveBuf(b,5); и посмотрите чему равно k и i (у меня к:=100,i:=5)
Это написано только для показа, что принимает ReceiveBuf не больше, чем я ему указал. Меньше может вернуть, больше нет.


 
Сергей М. ©   (2007-07-30 15:44) [17]


> Evgeny V ©   (30.07.07 15:38) [16]



>  for i:=0 to 100 do
>   b[i]:=byte(i);
>  CS1.Socket.SendBuf(b,100);


SendBuf - функциональный  метод !!!!!!!!!!!!!!!

Это что, не очевидно ?

Ну нельзя же быть таким тупым, когда намекают на функциональную декларацию неких методов некоего объекта)


 
Сергей М. ©   (2007-07-30 15:48) [18]


> тольковый вы наш


Прекращай засранство и тестируй свой код в условиях глобальной сети - убедись что он НЕ работоспособен.


 
Evgeny V ©   (2007-07-30 16:01) [19]


> Сергей М. ©   (30.07.07 15:44) [17]


> SendBuf - функциональный  метод !!!!!!!!!!!!!!!

Ты придуриваешься или просто так. Да знаю я что функциональный, тебе просто пример дали, что бы ты в отладчике прошагал.
ты это читал


> Это написано только для показа, что принимает ReceiveBuf
> не больше, чем я ему указал. Меньше может вернуть, больше
> нет.
Я это специально написал, что бы указать, что нет у меня времени писать тебе программу, я дал тестовый код в котором вполне нормально видно, что приехало столько-то байт, а принято столько или меньше чем я указал. Если тебе охото проверить сколько услал клиент  -сделайэто в своем тесте. А вопрос в том, что ReceiveBuf вернет столько, сколько в очереди, верно лишь в том случае, если в очереди меньше или равно, чем я указал для приема, если в очереди больше, то ReceiveBuf вернет столько, сколько указано в параметре -  РАЗМЕР БУФЕРА, если конечно не было ошибок. Я думал по твоим ответам на форуме, что ты знаешь, а пока сейчас вижу только желание повставлять цитаты и показать свое знание.   Ну прошагай отладчиком, напиши цифирки, которые я указал... Спорим на пустом месте. Что принять можем или запросили или меньше, если в очереди меньше, чем запросили  Но не больше чем мы запросили (указали размер буфера)!  Это мое мнение, твое - что столько сколько в очереди, и если в очереди больше, чем мы просим, то мы примем больше???
Сергей М. ©   (30.07.07 14:06) [8]  Сколько queued, столько и вернет

И в конце ты все таки уже даешь


> Сергей М. ©   (30.07.07 14:44) [14]
> Min("запрошено", "физически доступно в очереди чтения")


А вот это верно. Изменил мнение или поправился? Так за что наезды, если я сказал сразу то же самое?

Или у тебя еще какие-то сомнения в

> Evgeny V ©   (30.07.07 14:03) [7]


Так возьми отладчик - 10 минут в дельфи сделать, то что я тебе написал и вперед- поделись результатами....


 
Evgeny V ©   (2007-07-30 16:04) [20]


> Сергей М. ©   (30.07.07 15:48) [18]
> Прекращай засранство

За своими словами последи, так пройдись по постам попорядку и посмотри где начались наезды и кто начал кидать термины


 
Сергей М. ©   (2007-07-30 16:04) [21]


> Evgeny V ©   (30.07.07 16:01) [19]
> Ты придуриваешься или просто так


Да, я "придуриваюсь", не закрывая глаза на то, что какой-то придурок ничтоже сумняшеся приводит код, игнорирующий результат вызова функционального метода, в то время как речь идет именно о необходимости анализа результатов вызовов таких методов, особенно в условиях глоб.сети !


 
Сергей М. ©   (2007-07-30 16:07) [22]


> Evgeny V ©   (30.07.07 16:04) [20]
>
>


Ты в этой ветке вообще что хотел сказать ?

ЕЩЕ раз повторяю, для ОСОБО бестолковых  - функция возвращает результат не для Пушкина, а для тебя !


 
Сергей М. ©   (2007-07-30 16:09) [23]


> Evgeny V


Коду, не анализирующему рез-ты send/recv-вызовов - место в мусорном ведре.
Рано или поздно он даст сбой.


 
Evgeny V ©   (2007-07-30 16:12) [24]


> Сергей М. ©   (30.07.07 16:04) [21]

Все понял.... А результаты теста у себя значит не привел? Или слабо было сделать свой такой же в локальной сети с компа на комп. Я бы сделал, но тебе доказывать наверное бесполезно, потому, что пока аргументов с твоей стороны, кроме как "сам дурак не увидел". Никого кода не увидел в качестве аргумента. Как сделаешь, приведи пожалуйста код, где
i:=Socket.ReceiveBuf(b,j);

и I при этом будет больше J, это же ты хотел сказать в
> Сергей М. ©   (30.07.07 14:06) [8]  Сколько queued, столько
> и вернет
.  Правда потом съехал на правильный ответ, ну так сразу надо писать правильно и понятно. Или признавать ошибки.
Все конец рабочего дня, иду домой. Будет код с  I > J, поговорим. А так это глухой телефон.


 
Сергей М. ©   (2007-07-30 16:13) [25]


> пройдись по постам


Ну прошелся.

И по какому же поводу в [16] ты вперся в тему с кодом, не имеющим отношения к сабжу, но содержащим другие серьезные ошибки в очевидно логике ?


 
Сергей М. ©   (2007-07-30 16:15) [26]

Да, I никогда не будет больше J.

Но ведь Автор пытается писать эти J байт в файл, в то время как в буфере B актуальны всего лишь первые I байт !


 
Evgeny V ©   (2007-07-30 16:17) [27]


> Сергей М. ©   (30.07.07 16:09) [23]

А вот про анализ - возврата функций -согласен, ну так надо различать, то что тебе написали за 2 минуты для проверки утверждения тут же не отходя от кассы(о чем я и написал, когда выложил код) и рабочий проект. Скажи просто нашел к чему прицепиться. Если я тебе в тесте написал бы
I:= CS1.Socket.SendBuf(b,100) ты бы сразу сказал, ой да, больше принять мы не можем, чем заказали. Да неважно мне сколько он отправил в данном случае. Важно сколько принял... Так что давай  свой правильный код с I > тогда посмотрим.


 
Сергей М. ©   (2007-07-30 16:18) [28]


> про анализ - возврата функций -согласен


КАКОГО же хрена его нет в твоем коде ?)


 
Сергей М. ©   (2007-07-30 16:22) [29]


> Evgeny V ©   (30.07.07 16:17) [27]


И КАКОГО хрена ты не приводишь состояние св-ва, готносящегося к блокировке , коль ты так уверен ?)


 
Сергей М. ©   (2007-07-30 16:23) [30]


> Evgeny V


Или ты не понимаешь, что методы приема/передачи этого гобъекта ведут себя по-разному в зависимости от состояния этого св-ва ?)


 
Evgeny V ©   (2007-07-30 16:25) [31]


> Сергей М. ©   (30.07.07 16:15) [26]
> Да, I никогда не будет больше J.


И чего ты тогда споришь?
> в то время как в буфере B актуальны всего лишь первые I
> байт !


Да верно, и в его случае правда, что  I=J, так как байты уже в очереди или второй вариант - будет ошибка -1

> Evgeny V ©   (30.07.07 14:03) [7]
> , если по какой-либо причине например не возникнет ошибка.
>  Проверить бы не мешало, не трудно ведь:-))

Приведи код, где с указанным (проверь возврат функции) где это будет не так

1 Получем ReceiveLength
2 Читаем  ReceiveLength байт и получаем меньше на возврате (но не ошибку    -1)


 
umbra ©   (2007-07-30 16:28) [32]

во люди дают, говорят одно и тоже, и при этом ругаются!


 
Evgeny V ©   (2007-07-30 16:28) [33]


> Сергей М. ©   (30.07.07 16:23) [30]


> Сергей М. ©   (30.07.07 16:22) [29]

Блокировку поставь как тебе надо. Без разницы, у меня был неблокирующий. ReceiveLenghth получен до вызова приема в переменную и функция приема считает столько сколько попросил. Ладно все домой, вежливый вы наш. Завтра посмотрю, если у тебя будет код :-))


 
Сергей М. ©   (2007-07-30 16:30) [34]


> Evgeny V ©   (30.07.07 16:25) [31]



> Приведи код, где с указанным (проверь возврат функции) где
> это будет не так
>
> 1 Получем ReceiveLength
> 2 Читаем  ReceiveLength байт и получаем меньше на возврате
> (но не ошибку    -1)


Тебе в код Борланда носом тыкать надо, да ?

Изволь:

function TCustomWinSocket.ReceiveText: string;
begin
 SetLength(Result, ReceiveBuf(Pointer(nil)^, -1));
 SetLength(Result, ReceiveBuf(Pointer(Result)^, Length(Result)));
end;


Мне оправдать действия Борланда или сам дотумкаешь ?)


 
Сергей М. ©   (2007-07-30 16:34) [35]


> Evgeny V ©   (30.07.07 16:28) [33]


> Без разницы, у меня был неблокирующий


Да похрену какой он у тебя был, если твой код не работал в глоб.сети, когда твой сервер и/тлт твой клиент разнесены в разные (непредсказуемые) "углы" Тырнета.


 
DVM ©   (2007-07-30 16:38) [36]

Горячие финские парни!

Евгений вы же уже домой шли :)


 
Сергей М. ©   (2007-07-30 16:48) [37]


> DVM ©   (30.07.07 16:38) [36]


А вот и не подеремся)


 
Сергей М. ©   (2007-07-30 16:54) [38]


> Sleep(1000);// жду когда приедет побольше


Галиматья несусветная.


 
r.o.o.t ©   (2007-07-30 17:25) [39]

Lock;
 try
   Result := 0;
   if (Count = -1) and FConnected then
     ioctlsocket(FSocket, FIONREAD, Longint(Result))
   else begin
     if not FConnected then Exit;
     if ioctlsocket(FSocket, FIONREAD, iCount) = 0 then
     begin
       if (iCount > 0) and (iCount < Count) then
         Count := iCount;
     end;

     Result := recv(FSocket, Buf, Count, 0);
/...............................................................................

я думаю всегда будет i=j

при ReceiveText невсегда реч шла о методе Send/Receivebuf


 
r.o.o.t ©   (2007-07-30 17:30) [40]

лан все фигня вот следующий вопрос

GetMem(bufA,LengthA);
   Socket.ReceiveBuf(bufA^, LengthA);
   Reply:=StrPas(bufA)
SockHWND:= StrToInt(ClientID.Strings[i]);
          for j := 0 to ServerSocket1.Socket.ActiveConnections - 1 do
           if ServerSocket1.Socket.Connections[j].SocketHandle=SockHWND then
           begin
              ServerSocket1.Socket.Connections[j].SendBuf(bufA^,Length(bufa));
           end;

FreeMem(BufA);

Почему происходит утечка памяти???
т.е. размер приложения в памяти растет на велечину LengthA+30  
как это возможно ? неправельно освобождается bufA??


 
DVM ©   (2007-07-30 17:34) [41]


> Почему происходит утечка памяти???
> т.е. размер приложения в памяти растет на велечину LengthA+30
>  

Это ты как выяснил? В Диспетчер задач не гляди - там цифры странные несколько. Проверь c пом. FastMM4 или MemProof


 
r.o.o.t ©   (2007-07-30 17:42) [42]

а поподробнее..... код встудиюю

ну я на цифры посматрел сервак обслуживает условно 20 клиентов был в памяти 14203 стал 18203 и потихонечку растеть т.е. помере передачи информации.............


 
Evgeny V ©   (2007-07-31 08:13) [43]


> Сергей М.

Ваша лексика не вызвает к вам ни уважения, ни доверия к вашим знаниям. Кстати пройтись по постам я вам предложил, что бы вы  посмотрели на свои слова, как вы общаетесь с людьми. Это не только в этой ветке, но и в других. Аргументов у вас ноль. И видно что вы не глупый, но придуриваетесь явно, или как говорят шлея под хвост - как с тем тестом что я вам дал. Сама не сделали, ни исправили, если уж вам так приспичило на олиночной посылке проверить SendBuf, ни предложили своего варианта.   Аргументов у вас почти ноль. Есть верные мысли -о проверки возврата методов, о том, что вряд ли найдется необходимость получать количество данных при использовании сокетов (по крайней мере блокирующих), но тем не менее такой подход есть, в том числе и у MS.  И создается впечатление, что вы усвоили штампы, верные штампы. Но знаний по теме у вас практически нет. Возможно я ошибаюсь, но обратных аргументов этому вы привести не смогли. Код борланда, который вы привели ничего не доказывает. Скажите мне причину, при которой будет считано меньше байт из буфера, чем заказано и эти байты там есть и доcтупны?  Причина - ошибка операции чтения.  Об этом говорилось.  Спорить вы не умеете, объяснять вам что-то не охото, как и слушать ваши виляния -" то так то этак, а может так " А засим разрешите откланяться, хамовитый вы наш. Думаю вас это все равно не проймет, ибо хамство судя по всему у вас стиль жизни.


 
Сергей М. ©   (2007-07-31 08:47) [44]


> r.o.o.t ©   (30.07.07 17:25) [39]


> думаю всегда будет i=j


Еще раз вникни в [6].


> при ReceiveText невсегда реч шла о методе ..Receivebuf


см. [34]

ReceiveText сводится к вызову ReceiveBuf.

При этом длина результ.строки сначала устанавливается равной amount of data (ReceiveLength тоже сводится к вызову ioctlsocket(FIONREAD)), а затем эта длина может быть уменьшена до фактического (положительного) размера, возвращенного вызовом ReceiveBuf.


 
Сергей М. ©   (2007-07-31 08:51) [45]


> r.o.o.t ©   (30.07.07 17:30) [40]


Тоже самое касается и вызовов SendText/SendBuf-методов - в неблок.режиме анализ результатов их вызовов обязателен.


 
sergeyst ©   (2007-07-31 11:15) [46]


> Evgeny V ©   (31.07.07 08:13) [43]

Зачем так безаппеляционно? Оппоненту надо было оставить шанс поспорить, а теперь он потерян... А жаль, было очень интересно!


 
SlymRO ©   (2007-07-31 11:50) [47]

sergeyst ©   (31.07.07 11:15) [46]
чемто напомнило анекдот про то как два кавбоя бесплатно дерьма наелись


 
Evgeny V ©   (2007-07-31 14:27) [48]

I>
> sergeyst ©   (31.07.07 11:15) [46]


потому и безапеляционно, что не люблю когда единственный аргумент  хамство.

Если тебе интересно, то расскажу.


> Сергей М. ©   (30.07.07 10:17) [6]
> Цитата из Winsock API Reference (ioctlsocket):
>
> If s is stream oriented (for example, type SOCK_STREAM),
>  FIONREAD returns an amount of data which can be read in
> a single recv; this may or may not be the same as the total
> amount of data queued on the socket


Эта цитата на которую ссылался как на якорь Сергей М. говорит только об одном . Что FIONREAD для потокоориентированнхы сокетов возвращает  количество данных, которые могут быть считаны одиночным вызовом recv. И это число может быть равно или не равно общему числу данных в очереди (буфере -мне удобней так называть) сокета. FIONREAD вызыватеся в ReceiveBuf, если параметром Count передать -1.

То есть отсюда мы видим, что есть два числа характеризующих очередь сокета. Они равны, или нет, это возвращаемое FIONREAD и общее число данных. Пока все - оснований делать вывод о том, что ReceiveBuf с Count=FIONREAD вернет больше Сount или меньше или равно нет. Интересно, какое из чисел больше  - общее число байт в очереди (хотя название вроде и говорит за себя) или возвращаемое FIONREAD (ReceiveLength). Для этого читаем про FIONREAD подробнее "FIONREAD still returns the amount of pending data in the network buffer, however, the amount that can actually be read in a single call to the recv function is limited to the data size written in the send or sendto function call. "
FIONREAD возвращает число ожидающих в сетевом буфере данных, которые могут быть считаны одиночным  вызовом функции recv, ограниченной размером данных, которые могут быть записаны Send или SendTo. тут надо понимать, что в буфере сокета данные могут накапливаться. Если не было вызовов recv, но было несколько Send на наш сокет, то общее число данных в буфере и есть сумма пришедших данных от этих Send. Но есть ограничение на размер данных - размер фрейма, который можно передать одним вызовом Send. Это же ограничение и есть  максимально возможное число, возвращаемое FIONREAD, то есть за раз мы не можем считать recv больше этого числа, хотя общее число данных в буфере может быть больше. То есть нам надо сделать несколько чтений

Таким образом получаем, что FIONREAD <= общее число данных в буфере.

Теперь читаем про recv
"For connection-oriented sockets (type SOCK_STREAM for example), calling recv will return as much data as is currently available—up to the size of the buffer specified."
Для ориентированных на соединение сокетов ( например SOCK_STREAM  )  вызов recv возвращает столько данных, сколько сейчас доступно, но не более верхней границы буфера. Все - этого достаточно.
Вызов i:=ReceiveBuf(buf[0],Count) может дать I < Count, если мы задали какой-то Count, больший чем число данных в буфере (очереди), доступных для одиночного вызова Recv или данных там нет, или просто меньше Count.

Но если мы сделали Count:=ReceiveLength; - получили число данных доступных - действительно доступных в буфере для одиночного вызова Recv (FIONREAD ), то при i:=ReceiveBuf(buf[0],Count)  мы получим I=COUNT ("return as much data as is currently available"). Возможен вариант, когда I=0 и не равен COUNT, или -1  -это при gracefully (бережном) закрытии сокета "If the connection has been gracefully closed, the return value is zero",  или -1 (SOCKET_ERROR), если в буфере не было данных для чтения при неблокирующей работе сокета.  Других вариантов в документации нет(уточню -я не видел). По моему опыту работы с сокетами - это подтверждается, не было так, что бы в результате I:=3, а COUNT был 4 (при условии, что Сount=ReceiveLength). А  I > Count - это вообще невозможно. Что касается кода от борланда ReceiveText - я не знаю почему такой, как вариант, они просто освобождают буфер, если ReceiveBuf вернул 0.  Я могу предложить такую версию или версию перестраховки.  Чужая голова потемки. Вот в общем и все из-за чего был спор.


 
Сергей М. ©   (2007-07-31 14:36) [49]


> По моему опыту работы с сокетами - это подтверждается, не
> было так, что бы в результате I:=3, а COUNT был 4


Значит твой опыт круче опыта Борланда)
И по этому случаю место коду ReceiveText  - свалка)


> I > Count - это вообще невозможно


Да неужели ?
А я только это и пытался доказать)))))))


 
Evgeny V ©   (2007-07-31 14:45) [50]


> Сергей М. ©   (31.07.07 14:36) [49]
> Сколько queued, столько и вернет


Ваши слова?  А про то, что надо понимать что такое очередь ваш вопрос? А про то, что в очереди может быть больше данных, чем ReceiveLength вы  знаете?  
Впрочем извинияюсь, опять начинается бодяга, а мне не охото это продолжать.

Про борланд не скажу, не считаю себя сильным программистом, но свой хлеб вполне нормально отрабатываю. Но вполне допускаю, что могут быть и те варианты которые я назвал.


 
Сергей М. ©   (2007-07-31 14:49) [51]


> не считаю себя сильным программистом


У тебя есть шанс стать более сильным, изучив TCP-протокол и виндовый TCP-стек в части его реализации.


 
Сергей М. ©   (2007-07-31 14:51) [52]


> Evgeny V


Ну а вот это

Sleep(1000);// жду когда приедет побольше

как было галиматьей, так ей и остается)


 
Сергей М. ©   (2007-07-31 15:49) [53]


> Evgeny V


Где ты, чудо ?

Парируй).. По поводу "галиматьи" хотя бы) ...


 
sergeyst ©   (2007-07-31 15:52) [54]

Предлагаю устроить всеобщее голосование: кто прав и кто круче!


 
Сергей М. ©   (2007-07-31 15:55) [55]


> sergeyst ©   (31.07.07 15:52) [54]

Где твои посты по теме ? Нет их !
Долой шакал-провокаторов типа тебя)


 
sergeyst ©   (2007-07-31 16:00) [56]


> Сергей М. ©   (31.07.07 15:55) [55]

Вот ты и  проголосовал. Что ж, не могу не согласиться. Непредвзятость хорошее качество.


 
Сергей М. ©   (2007-07-31 16:06) [57]


> sergeyst ©   (31.07.07 16:00) [56]
> Вот ты и  проголосовал


Ой врешь же !)


 
sergeyst ©   (2007-07-31 16:11) [58]


> Ой врешь же !)

Ну, а откуда тогда такие резкие выпады?


 
Сергей М. ©   (2007-07-31 16:12) [59]


> sergeyst ©   (31.07.07 16:11) [58]
>
>


> откуда тогда такие резкие выпады?
>


Просто нелюбовь у меня к шавкам)


 
sergeyst ©   (2007-07-31 16:42) [60]


> Сергей М. ©   (31.07.07 16:12) [59]

Хотелось бы узнать на каком основании ты награждаешь меня этим эпитетом.


 
SlymRO ©   (2007-08-01 05:34) [61]

Удалено модератором
Примечание: Отдохни недельку, поучи русский язык



Страницы: 1 2 вся ветка

Форум: "Начинающим";
Текущий архив: 2007.08.26;
Скачать: [xml.tar.bz2];

Наверх





Память: 0.65 MB
Время: 0.042 c
15-1185806075
DillerXX
2007-07-30 18:34
2007.08.26
Я может слишком жалостлив к людям, но...


5-1159188378
Rat Rat
2006-09-25 16:46
2007.08.26
Перерисовка, TCanvas и стандартные компоненты.


2-1184414949
MRAk
2007-07-14 16:09
2007.08.26
Ужасно ли использование таймера


2-1186160090
sashap
2007-08-03 20:54
2007.08.26
Замена popmenu в tstringgrid е


2-1185790796
pukin
2007-07-30 14:19
2007.08.26
Найду ли я динамически созданный компонент?





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский