Page 1 of 3
Problem with ReceiveData
Posted: Mon Apr 22, 2019 12:03 pm
by msu
Hello!
My Hollywood program receives data from a PostgreSQL server.
The network connection will persist during the session.
The connection is NOT terminated by the server.
Unfortunately, ReceiveData behaves pretty useless in this case.
#RECEIVELINE is not working. The server also sends binary data.
#RECEIVEBYTES works, but unfortunately the program pauses until the network timeout is reached.
Unfortunately, #RECEIVEALL behaves the same way.
The problem has nothing to do with the database server.
The problem also occurs with other servers that do not disconnect.
Is there a solution?
Greetings Michael
Re: Problem with ReceiveData
Posted: Mon Apr 22, 2019 8:44 pm
by plouf
so independed of hollywood limitation,
How do you know that your server (SQL) has send all data ?!
Re: Problem with ReceiveData
Posted: Mon Apr 22, 2019 8:58 pm
by msu
Hello plouf!
I did the following:
- I used a different programming language. Everything worked very well.
- To be really sure, I used the software "Wireshark".
There were no more messages.
Re: Problem with ReceiveData
Posted: Mon Apr 22, 2019 9:23 pm
by msu
Here's an example:
Server:
Code: Select all
CreateServer(1,2900)
Function p_ConnectFunc(msg)
Switch(msg.action)
Case "OnDisconnect":
CloseConnection(msg.id)
Case "OnConnect":
SendData(msg.clientid,"Hallo Klient")
EndSwitch
EndFunction
InstallEventHandler({OnConnect = p_ConnectFunc, OnDisconnect = p_ConnectFunc})
Repeat
CheckEvent
Forever
Client:
Code: Select all
OpenConnection(1, "localhost", 2900)
a$ = ReceiveData(1, #RECEIVEBYTES, 200)
NPrint(a$)
WaitLeftMouse
The client displays the message after 10 seconds (NetworkTimeout default).
Exactly the same behavior as with the database server.
Re: Problem with ReceiveData
Posted: Mon Apr 22, 2019 9:35 pm
by plouf
my question is diffirent
FORGET hollywood
if you request "somethink" in SQL server, how do you know the amount of data is going to be send ?
how does the "other" languange end communication ? based on what criteria ?!
Re: Problem with ReceiveData
Posted: Mon Apr 22, 2019 9:51 pm
by msu
plouf wrote: ↑Mon Apr 22, 2019 9:35 pm
FORGET hollywood
if you request "somethink" in SQL server, how do you know the amount of data is going to be send ?
That's the problem.
The amount of data is variable.
plouf wrote: ↑Mon Apr 22, 2019 9:35 pm
how does the "other" languange end communication ? based on what criteria ?!
This is not a problem.
The first byte is the message type. The following four bytes the length.
Everything traceable.
Re: Problem with ReceiveData
Posted: Mon Apr 22, 2019 11:05 pm
by plouf
then you must first
ReceiveData(id, #RECEIVEBYTES, 5) ; receive 5 bytes
then ReceiveData(id,#RECEIVEBYTES, your_calculated_amount_of_bytes)
Re: Problem with ReceiveData
Posted: Tue Apr 23, 2019 6:16 pm
by msu
Hi plouf,
plouf wrote: ↑Mon Apr 22, 2019 11:05 pm
then you must first
ReceiveData(id, #RECEIVEBYTES, 5) ; receive 5 bytes
then ReceiveData(id,#RECEIVEBYTES, your_calculated_amount_of_bytes)
I had already tried this solution.
Had I programmed correctly, that would have worked.
Here is my new code:
Code: Select all
Function PG:Receive(ConnectionID)
Local part$, c, count, memid, len, Answer$, exit$
Repeat
part$, c = ReceiveData(ConnectionID, #RECEIVEBYTES, 5)
Answer$ = Answer$ .. part$
count = count + c
memid = AllocMem(Nil, 6)
Poke(memid, 0, part$, #STRING)
len = Peek(memid, 1, #INTEGER)
FreeMem(memid)
len = len - 4
part$, c = ReceiveData(ConnectionID, #RECEIVEBYTES, len)
Answer$ = Answer$ .. part$
count = count + c
memid = AllocMem(Nil, len + 1)
Poke(memid, 0, part$, #STRING)
exit$ = Peek(memid, len - 1, #STRING, 1)
FreeMem(memid)
Until exit$ = "I" Or c = 0
Return(count, Answer$)
EndFunction
But the exit (Repeat / Until) still needs to be extended / improved.
I hope my bad English has not annoyed too much?
Greetings, Michael
Re: Problem with ReceiveData
Posted: Wed Apr 24, 2019 12:40 am
by plouf
dont understand, the above works or works not ?
Re: Problem with ReceiveData
Posted: Wed Apr 24, 2019 12:14 pm
by msu
Works well.