RecieveNetworkString()

[Rook Zimbabwe]

I am having issues with the ability to SendNetworkString() but NOT RecieveNetworkString()...

I think if we can Send we should be able to tell the tiny server we are writing to Recieve...

[Hroudtwolf]

Hi,

There isn't an network event for receiving strings
(#PB_NetworkEvent_String)

Best regards

Wolf

[netmaestro]

How would the compiler know that a string was in the pipeline without parsing virtually everything all the time, which would be a major slowdown? I suspect this could be the reason it isn't there. If you as programmer know that what's coming is a string, based on header info you prefixed it with, etc. you can just PeekS() at it. It doesn't add much difficulty to our task imho and it keeps things running full speed.

[Rook Zimbabwe]

@Hroud: I know... this was a request!

@Netmaestro: Hmmm the problem is maybe more complex than I have been thinking. I would have to peekS the length of the buffer. The problem I have been having is that what gets sent looks (as the server sees it as "DO this TO that WHERE this = SOMETHING;DO this TO that WHERE this = SOMETHING;" and so the query has more than 1 ";" in it

So it does not parse correctly.

I mean to send "DO this TO that WHERE this = SOMETHING;" and a second "DO this TO that WHERE this = SOMETHING;" (and possibly a third etc.)

The only way I can do this now is to force a delay of at least Delay(878) between each SendNetworkString() event...

I am trying to build an internal parser into the SQL Server. I haven't reasoned it out yet.

[citystate]

The only way I can do this now is to force a delay of at least Delay(878) between each SendNetworkString() event...

You could send a zero byte after each string to force a end to the received string - you'd need to check the length of the string vs the buffer size in case of multiple strings being sent though, and parse the result, but that's easy enough to do...

[Dare]

Hi RZ,

I know this is your feature request and not a request for solutions, so forgive this post.

What exactly is happening at the receive end? You are losing some data? Getting mangled data? Or not getting any at all (data that is, with the other you will need to seek help elsewhere!)?

I am assuming you get some data, not all, or all data but mangled in some way.

Also (assuming you control both ends of the deal) you can structure the outgoing data in any way you want and reassemble it on the incoming side. So if you can provide an eg of what you are sending (not code, just data) perhaps we can work out a methodology that fixes the prob.


Ignore this post if it is (a) out of line (b) out of context (c) out of date or (d) I am out of my mind.

[Foz]

I have a routine called SendNetworkDataEx and ReceiveNetworkDataEx, but the ReceiveNetworkDataEx throws an event with the data once it has received everything and it is all valid.

I'm using to send and receive variable length XML files for use with my RPC toolkit.

Would this be of any use? If so, I'll post it up to the Tips and Tricks section later.

[Dare]

Hi Foz.

I would be interested in seeing and learning from your routines! Anything that improves my understanding or offers insights is welcome.

I am sure at least a few others would also be interested in seeing what they could pick up from your approach and code.

[freak]

There used to be a ReceiveNetworkString() function and a corresponding event,
but the problem was that it cannot be reliably decided when some random data
is a string and when its not. Thats why it was removed.

> I mean to send "DO this TO that WHERE this = SOMETHING;" and a second "DO this TO that WHERE this = SOMETHING;" (and possibly a third etc.)

> The only way I can do this now is to force a delay of at least Delay(878) between each SendNetworkString() event...

You cannot expect to be receiving the data in the same chunk sizes as you sent it.
The data is sent as a stream, so there is no way of telling the chunk sizes at the other end.
A Delay() will not help, as a very slow network connection could still cause the first part
to be delayed so much that both arrive at the same time on the target.

You have to be prepared to receive the data in any chunk sizes, both larger or
smaller than what you originially sent.

[Rook Zimbabwe]

Foz: I would very much like to see how you did it!

[uwekel]

I would appreciate having a ReceiveNetworkString() as well. I think it is not that problematic. I did something similar for myself. It is not a matter whether or not we are dealing with binary or string data. The programmer decides. If he uses ReceiveNetworkString(), string data will be expected. The function must look for the next #CRLF$ line feed in the data buffer and returns the data as a string. If there is no more data in the buffer, the function must block until new data received. But you have to take care that even a #CRLF$ can be split!