John Rule wrote:
I think the inconsistency lies in the lack of documentationThe documentation for UDP sockets is pretty sparse (or indeed, totally missing, and trying to use the existing docs is near impossible, because the differences between TCP and UDP sockets are quite significant).
regarding 'when' to use the 'with message' and 'how' RunRev is calling these
(or possibly this is a bug). For example:
Dar Scott provided me with lots of help a while ago - you may find more useful info in the email archives (around September).
Summary (of what worked for me - may be other ways)
1.To accept packets from others (i.e. be a server), then you do :
-- note this command name is misleading
-- for UDP, the "accept" simply registers this object to receive packets on this port
-- and sets up the callback function to call when such a packet arrives
repeat for each word W in lPorts
accept datagram connections on port W with message "gotPacket"
end repeat
and then the handler "gotPacket" will be called with each arriving packet. In this case here, I simply reply to it ..
-- Server mode handlers
on gotPacket pHostPort, pData, pSock
local tHostPort
mylog "Packet arrived from" && pHostPort && "on my socket" && pSock
mylog " contents:" && pData
open datagram socket to pHostPort
write "reply with " & pData to socket pHostPort
close socket pHostPort
end gotPacket
2. To be a client:
-- open datagram socket: UDP is connectionless, so no network activity
-- is required for this open - hence it will complete immediately.
-- the message callback is used to receive any replies to packets sent over this socket
open datagram socket to lHostPort with message "gotReplyPacket"
and then this "gotReplyPacket" will be called for any packets replied to as above; in my case
That works for me - though I haven't tested it in any high-stress environment - it's been PC to PC, for "chat"-like apps, nothing that would send, for instance, a stream of back-to-back packets.-- Client mode handlers on gotReplyPacket pOtherOne mylog "Packet arrived" && paramCount() repeat with i=1 to paramCount() mylog i && ":" && param(i) end repeat end gotReplyPacket
I don't have any code that reads from a UDP socket (that's not to say it can't be done - but all my code uses handles as in my examples above).The handler "getData" is not called everytime, and the parameters only have data 'sometimes', but my 'sniffer' shows that my device is ALWAYS responding. What is the appropriate sequence, and WHEN does RunRev call these 'with message' handlers?! I am getting unreliable results using ANYTHING!
Logically, you would think that once I instruct the handler to 'read' from a UDP socket whenever it gets data (i.e. I have set the callback handler), it should ALWAYS call this handler when data is received on that open udp socket.
Or, when I write data to an open udp socket with a handlerThere is no need (and probably no point in having) a "with callback" on UDP writes.
message, if the destination socket responds with data, the handler should be
called immediately. It does not ALWAYS work this way, but it is close, so I
believe there is a problem.
TCP sockets can be "blocked" because we've reached the maximum number of outstanding bytes, and cannot send any more until the remote system has received (and ACKed) some of what we've already sent; hence there may be a significant delay before the data can be sent - so rather than wait for that, you can pass in the callback handler, continue working and later be told when the data has gone.
UDP has no such issues - so the only delay possible would be network buffering (e.g. if you were sending to a very slow line). The call back function in the write should be called immediately - it has nothing to do with the remote system, and nothing to do with any response having been received.
I do not have issues with regular sockets, just datagram sockets...
Here are my questions that I cannot find an answer to in the documentation:
- Once the "getData" handler is set, how often is it called?
Should be called every time a packet is received for that socket
- If I write to an open UPD socket with a handler message, is the handlerquestion doesn't compute .... data received is passed to the handler specified in either a
called 'anytime' data is received, or only for that call (i.e. am I setting
some internal function pointer)?
"accept connections"
or an
"open datagram socket"
- Is the data stored somewhere when it is received for retrieval using 'read
from socket'?
Don't use read from socket :-)
- Is the data accumulated? How large is the buffer? Can I set this?No.
Presumably, max packet size.
No (UDP is datagram oriented - so you send and/or receive single data packets)
- How many parameters are there for the handlers?
For the "getpacket" handlers, 3 - host, port, data For the "write" handler (which I suggest you don't use) - 1
- Once I set the callback handler, is it 'always' set? Is it reset when theWhen the socket is closed, there will be no more calls - irrelevant whether it is reset or not.
socket is closed?
If the socket is re-opened, that will set a new callback handler
- If I set a callback handler for ANY call (i.e. open 'with', write 'with',As far as I know, for UDP you should set handlers only with open and accept, and (assuming you got port numbers, etc. right) those should be called for all data received.
read 'with', accept 'with') is this handler going to be called for ANY data
received?
I feel like I am shooting in the dark, and I am disappointed thatI'm sure no info is being "withheld"; it's a deficiency in the docs, not anything being withheld.
this information is not somewhere in the docs. Withholding this info (for
'Enterprise' or 'RevList' users) does not make me want to upgrade...it makes
me want to look somewhere else for solutions.
UDP sockets are not widely used; I suspect there are only a fairly small number of people writing code that uses them, and they've each evolved a way that works for them. But on the other hand, there are a number of real users out there, so it can be made to work (at least in many cases).
And for all we know, you may have encountered a bug.
If the above doesn't help - feel free to email me your code I'll take a look over it and see if I have any suggestion
-- Alex Tweedly http://www.tweedly.net
-- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 266.5.1 - Release Date: 27/02/2005
_______________________________________________ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
