Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Pages: [1]
1
The Rest - Ask For Help / NetSimple Client sending multiple packets on a thread
« on: August 31, 2011, 03:50:38 PM »
I have a NetSimple client on a thread that gets a Notify to send a SysyID of a data record. Once I have done the Send how can I know when I can open a new connection and send another record.
It comes down to will a Notify come in during the period after I open the previous connection but before the send. I can set a blocking flag between the open method and the send method and buffer the requests to a queue. So I am fine between the open and send. Can I open a new connection right after I do the Send or do I need to watch for something else on a timer to know when the next open can be called.
During this period between open and send will Notify events be able to post? I assume while waiting for the connection to open they can but once I trap the open connection and start the send it can't. This leaves the post send period in question.
Since the IP and Port are the same it seems launching a new thread for each transmission won't solve the problem but would stack up the port opens. Would that be true?
It comes down to will a Notify come in during the period after I open the previous connection but before the send. I can set a blocking flag between the open method and the send method and buffer the requests to a queue. So I am fine between the open and send. Can I open a new connection right after I do the Send or do I need to watch for something else on a timer to know when the next open can be called.
During this period between open and send will Notify events be able to post? I assume while waiting for the connection to open they can but once I trap the open connection and start the send it can't. This leaves the post send period in question.
Since the IP and Port are the same it seems launching a new thread for each transmission won't solve the problem but would stack up the port opens. Would that be true?
2
The Rest - Share Knowledge / Getting length from a non Clarion NetSimple packet
« on: August 23, 2011, 06:53:58 PM »
The WholePacket NetSimple Methodis great for NetTalk to NetTalk objects since it sends the length as a 4 byte header and can assemble the packets for you saving some code. (See the manual boundary example).
There is a standard way that many non NetTalk TCP applications use. They send the length as a 4 bytes header but it is no Clarion LONG you can distinguish.
The Bytes are sent as a Big Endian ULONG Integer. This is great until you find out Clarion is not Big Endian So we pretend it's a STRING instead and it's all better. You just need a little funny math.
Should Capesoft add an option to WholePacket to use Big Endian longs they could make WholePacket work with other players as well as Clarion and it wouldn't break anyones code since we compute length as a Clarion LONG, but NetTalk could use Big Endian as an option and we wouldn't care since it is doing all the work.
The following functions will convert properly (we tested it today with a an Online service)
ToBigEndian PROCEDURE (LONG RawVal),STRING
ByteArray BYTE,DIM(4)
OutputVal STRING(4),OVER(ByteArray)
CODE
ByteArray[1] = INT(RawVal/256^3)
ByteArray[2] = INT((RawVal % 256^3) / 256^2)
ByteArray[3] = INT((RawVal % 256^2) / 256)
ByteArray[4] = INT(RawVal % 256)
RETURN OutputVal
And to go the other way:
FromBEndian PROCEDURE (STRING RawVal), LONG
ByteArray BYTE,DIM(4)
InputVal STRING(4),OVER(ByteArray)
Result LONG
CODE
InputVal = RawVal
Result = (INT(ByteArray[1]) * 256^3 + |
INT(ByteArray[2]) * 256^2 + |
INT(ByteArray[3]) * 256 + |
INT(ByteArray[4])) ! The packet includes the 4 byte header
RETURN Result
Special thanks to Marc Walgren of MItten Software for being the tester that would have asked me to fix it if it didn't work..
There is a standard way that many non NetTalk TCP applications use. They send the length as a 4 bytes header but it is no Clarion LONG you can distinguish.
The Bytes are sent as a Big Endian ULONG Integer. This is great until you find out Clarion is not Big Endian So we pretend it's a STRING instead and it's all better. You just need a little funny math.
Should Capesoft add an option to WholePacket to use Big Endian longs they could make WholePacket work with other players as well as Clarion and it wouldn't break anyones code since we compute length as a Clarion LONG, but NetTalk could use Big Endian as an option and we wouldn't care since it is doing all the work.
The following functions will convert properly (we tested it today with a an Online service)
ToBigEndian PROCEDURE (LONG RawVal),STRING
ByteArray BYTE,DIM(4)
OutputVal STRING(4),OVER(ByteArray)
CODE
ByteArray[1] = INT(RawVal/256^3)
ByteArray[2] = INT((RawVal % 256^3) / 256^2)
ByteArray[3] = INT((RawVal % 256^2) / 256)
ByteArray[4] = INT(RawVal % 256)
RETURN OutputVal
And to go the other way:
FromBEndian PROCEDURE (STRING RawVal), LONG
ByteArray BYTE,DIM(4)
InputVal STRING(4),OVER(ByteArray)
Result LONG
CODE
InputVal = RawVal
Result = (INT(ByteArray[1]) * 256^3 + |
INT(ByteArray[2]) * 256^2 + |
INT(ByteArray[3]) * 256 + |
INT(ByteArray[4])) ! The packet includes the 4 byte header
RETURN Result
Special thanks to Marc Walgren of MItten Software for being the tester that would have asked me to fix it if it didn't work..
3
The Rest - Ask For Help / NetSimple responsding to Telnet
« on: August 18, 2011, 06:10:57 PM »
We are connecting to a service provider via NetSimple Server / client. We will submit requests and they will respond (not real time) via a NetSimple Server. They want to be able to do a test with Telnet. This is a VPN connection so it's secure and we can restrict access to the server. The question is How can we respond to a telnet connection using NetTalk? Ideally it's the only thing this NetTalk server thread would do.
4
The Rest - Ask For Help / NetSimple Server
« on: August 15, 2011, 10:42:38 AM »
I need a NetSimple server to receive a packet that will be an XML data file that I know how to read. This connection will come through a VPN and of course the one client calling is the only client that can call over the VPN but it won't be a Clarion application that can use NET:SimpleWholeDataPacket.
The XML structure is standard but the contents are variable length but will be well under 16KB more like 2KB. When I receive the partial packet how do I know when the whole packet has been received? Unlike when I use the NET:SimpleWholeDataPacket I won't really know. Given the dedicated link it should all be there very quick but how quick is pretty quick:)
The XML structure is standard but the contents are variable length but will be well under 16KB more like 2KB. When I receive the partial packet how do I know when the whole packet has been received? Unlike when I use the NET:SimpleWholeDataPacket I won't really know. Given the dedicated link it should all be there very quick but how quick is pretty quick:)
Pages: [1]