2010/1/5 Doriano Blengino :
> Kadaitcha Man ha scritto:
>> 2010/1/5 Doriano Blengino :
>>
>> I disagree. Blocking mode guarantees known certainties, as defined by
>> any number of RFC documents.
>>
> Pardon me... I think that RFCs have nothing to do with blocking mode,
lol - RFCs have everything t
Kadaitcha Man ha scritto:
> 2010/1/5 Doriano Blengino :
>
> I disagree. Blocking mode guarantees known certainties, as defined by
> any number of RFC documents.
>
Pardon me... I think that RFCs have nothing to do with blocking mode,
unless you find an RFC which says "an operating system SHOU
2010/1/5 Doriano Blengino :
> Kadaitcha Man ha scritto:
>> 2010/1/4 Doriano Blengino :
>>> I think that there is
>>> something extreme in trying to send large chunks of data in a single
>>> instruction,
>>>
>>
>> Wlll... Not necessarily. If the document is imprecise, which
>> it most defin
Kadaitcha Man ha scritto:
> 2010/1/4 Doriano Blengino :
>> I think that there is
>> something extreme in trying to send large chunks of data in a single
>> instruction,
>>
>
> Wlll... Not necessarily. If the document is imprecise, which
> it most definitely is, it is fair to make assu
2010/1/4 Doriano Blengino :
> Kadaitcha Man ha scritto:
>> 2010/1/4 Doriano Blengino :
>>
>>
>>> My idea was to raise an event when a line has been read
>>>
>>
>> Based on what I just posted to the developer's list, you will need to
>> be specific about what defines an end of line. For example:
>>
Kadaitcha Man ha scritto:
> 2010/1/4 Doriano Blengino :
>
>
>> My idea was to raise an event when a line has been read
>>
>
> Based on what I just posted to the developer's list, you will need to
> be specific about what defines an end of line. For example:
>
> NUL ^@ \0 Null c
2010/1/4 Doriano Blengino :
> My idea was to raise an event when a line has been read
Based on what I just posted to the developer's list, you will need to
be specific about what defines an end of line. For example:
NUL ^@ \0 Null character
ETX ^C End of Text
LF
2010/1/4 Doriano Blengino :
> My idea was to raise an event when a line has been
> read
As an optional setting, that would be absolutely brilliant and would
resolve a number of potential and real problems.
> I would like an event for every line,
I too would like an event for every line.
> an e
2010/1/4 Doriano Blengino :
> This is the TCP scenario: you send data, and don't know what the hell
> those data have done - only that it is arrived. Never tried to speak FTP
> to a server which talks HTTP? Or to speak HTTP to a CIFS server?
Yes, I have. Many, many times.
> There
> must be a hig
2010/1/4 Doriano Blengino :
> the normal syntax implies that the value you read is
> available just after; in this case, one should "declare" that he wants
> to read a line,
YES! YES! YES!
Pardon my excitement.
> The timeout, as seen in this discussion, could be settable for error
> raising pur
2010/1/3 Benoît Minisini :
>
>
> I'm not sure that the MSDN documentation is a good reference for socket
> programming:
>
> - The Microsoft documentation is often not connected to the reality it tries
> to describe.
>
> - The Windows socket implementation often behaves differently than the other
Benoît Minisini ha scritto:
>> Benoît Minisini ha scritto:
>>
[lot of talk]
>>> The point of view of the client and the server are not the same:
>>>
>>> The client likes blocking socket. It usually asks or sends something to
>>> the server, waits for the answer, and so on...
Kadaitcha Man ha scritto:
> 2010/1/3 Doriano Blengino :
anyway, this is a truely complicated matter.
>>> It is only complicated if you believe that the socket should poke its
>>> nose into business it shouldn't :)
>>>
>>> If the connection goes belly up, the socket can, at b
> Benoît Minisini ha scritto:
> >> [lot of talk]
> >
> > The point of view of the client and the server are not the same:
> >
> > The client likes blocking socket. It usually asks or sends something to
> > the server, waits for the answer, and so on... It usually does one thing
> > at once.
> >
> >
Benoît Minisini ha scritto:
>> [lot of talk]
>>
>
> The point of view of the client and the server are not the same:
>
> The client likes blocking socket. It usually asks or sends something to the
> server, waits for the answer, and so on... It usually does one thing at once.
>
> On the contr
> [lot of talk]
The point of view of the client and the server are not the same:
The client likes blocking socket. It usually asks or sends something to the
server, waits for the answer, and so on... It usually does one thing at once.
On the contrary, the server should serve multiple client con
2010/1/3 Doriano Blengino :
> Kadaitcha Man ha scritto:
>> 2010/1/3 Doriano Blengino :
>>
>>> After a few minutes I suggested that a timeout could simplify things, I
>>> changed my mind. It would not be a totally bad idea but, as most other
>>> mechanisms, it has its problems. First, what is the ri
Kadaitcha Man ha scritto:
> 2010/1/3 Doriano Blengino :
>
>> After a few minutes I suggested that a timeout could simplify things, I
>> changed my mind. It would not be a totally bad idea but, as most other
>> mechanisms, it has its problems. First, what is the right timeout?
>>
>
> It is e
2010/1/3 Doriano Blengino :
> Kadaitcha Man ha scritto:
> After a few minutes I suggested that a timeout could simplify things, I
> changed my mind. It would not be a totally bad idea but, as most other
> mechanisms, it has its problems. First, what is the right timeout?
It is either 0 for no tim
Kadaitcha Man ha scritto:
> 2010/1/3 Doriano Blengino :
>
>
>> after a timeout occurs, one can only assume that
>> the entire write has failed, even if, in fact, some data has been
>> succefully written.
>>
>
> Yes, you are quite correct, but the problem of partial data transfer
> due to a
2010/1/3 Benoît Minisini :
> By default, Socket are in non-blocking mode (Blocking property set to False).
> So writing to it a big chunk fails. The bug is that instead of raising an
> error during the Write instruction, it fails silently.
>
> By having a blocking socket, your program works.
>
> S
2010/1/3 Benoît Minisini :
>> 2010/1/3 Kadaitcha Man :
>> > 2010/1/3 Benoît Minisini :
>> >
>> > http://gambasdoc.org/help/comp/gb.net/socket
>> >
>> > I will see about updating the Socket page and add the Blocking
>> > property to the list of inherited properties.
>>
>> Before I do that, is Blocki
2010/1/3 Benoît Minisini :
>>
>> Yes, I'll look at that, but why in the Ready event? Would there be any
>> disadvantage or problem with setting the socket to block permanently
>> when it is instantiated and its properties setup in code? Also, if it
>> is set in the Ready event, would it needlessly
> 2010/1/3 Kadaitcha Man :
> > 2010/1/3 Benoît Minisini :
> >
> > http://gambasdoc.org/help/comp/gb.net/socket
> >
> > I will see about updating the Socket page and add the Blocking
> > property to the list of inherited properties.
>
> Before I do that, is Blocking gb3 specific?
>
Yes.
--
Beno
>
> I will see about updating the Socket page and add the Blocking
> property to the list of inherited properties.
>
The Blocking property is already in the list of inherited properties. This is
done automatically by the wiki.
Regards,
--
Benoît Minisini
>
> Yes, I'll look at that, but why in the Ready event? Would there be any
> disadvantage or problem with setting the socket to block permanently
> when it is instantiated and its properties setup in code? Also, if it
> is set in the Ready event, would it needlessly get set again every
> time the
2010/1/3 Kadaitcha Man :
> 2010/1/3 Benoît Minisini :
> http://gambasdoc.org/help/comp/gb.net/socket
>
> I will see about updating the Socket page and add the Blocking
> property to the list of inherited properties.
Before I do that, is Blocking gb3 specific?
2010/1/3 Doriano Blengino :
> after a timeout occurs, one can only assume that
> the entire write has failed, even if, in fact, some data has been
> succefully written.
Yes, you are quite correct, but the problem of partial data transfer
due to a timeout is not a problem for the socket to sort ou
2010/1/3 Benoît Minisini :
>> > 2010/1/2 Benoît Minisini :
>> >> Please provide the source code of the network communication,
>> >> otherwise I can't see what you are doing exactly.
>>
>> Ok, here is some code that adequately reproduces the problem, and the
>> exact same code with a smaller chunk
Benoît Minisini ha scritto:
>>> 2010/1/2 Benoît Minisini :
>>>
Please provide the source code of the network communication,
otherwise I can't see what you are doing exactly.
>> Ok, here is some code that adequately reproduces the problem, and the
>> exact same code wi
> > 2010/1/2 Benoît Minisini :
> >> Please provide the source code of the network communication,
> >> otherwise I can't see what you are doing exactly.
>
> Ok, here is some code that adequately reproduces the problem, and the
> exact same code with a smaller chunk of text that does not have the
>
> 2010/1/2 Benoît Minisini :
>> Please provide the source code of the network communication,
>> otherwise I can't see what you are doing exactly.
Ok, here is some code that adequately reproduces the problem, and the
exact same code with a smaller chunk of text that does not have the
problem.
Soc
2010/1/2 Benoît Minisini :
> Do you mean that if you write more than 41K of data on a Socket, it fails
> silently?
Yes, precisely.
> Please provide the source code of the network communication,
> otherwise I can't see what you are doing exactly.
I will have to mock something up over the coming
> gb3, qt4 on Ubuntu 9.10.
>
> Are there any known limits on the size of data that can be sent down a
> socket in one gulp?
>
> I have a proxy written in gb3 that uses Socket to communicate with a
> remote server and uses ServerSocket to get data from the client.
> ServerSocket seems to gag when
gb3, qt4 on Ubuntu 9.10.
Are there any known limits on the size of data that can be sent down a
socket in one gulp?
I have a proxy written in gb3 that uses Socket to communicate with a
remote server and uses ServerSocket to get data from the client.
ServerSocket seems to gag when given anything a
35 matches
Mail list logo
