This article applies to:
E-Prime 3.0
E-Prime 2.0
This item was introduced in E-Prime 2.0 (2.0.10.174).
Detail
A Socket device allows support of stream-based network communications. The Socket device utilizes TCP(Transmission Control Protocol), UDP(User Datagram Protocol), and byte order selection.
The Socket device can be added to an experiment via the Devices tab of the Experiment Object's property pages. Addition of the Socket Device on the Experiment Object allows specification of connection settings for the Socket Device directly.
-
Server - The IP address or DNS name of the server attempting to be connected
-
Port - The port number that the server is listening
-
Connection Type - TCP or UDP
-
Byte Ordering – Native, Network, LittleEndian, and BigEndian
-
Native - Buffer in the current hardware's "native" ordering (that is, the order in which your machine's CPU writes words to memory).
-
Network - The order in which the bytes of a multi-byte number are transmitted on a network - most significant byte first (as in "big-endian" storage). This may or may not match the order in which numbers are normally stored in memory for a particular processor.
-
LittleEndian - The low-order byte of the number is stored in memory at the lowest address, and the high-order byte at the highest address. (The little end comes first.)
-
BigEndian - The high-order byte of the number is stored in memory at the lowest address, and the low-order byte at the highest address. (The big end comes first.)
UDP, by its nature, does not guarantee the delivery of packets, and if a packet is delivered, the delivery is not guaranteed to be in the correct order. UDP is faster but does not assure that intended data will actually be sent, whereas TCP is slower but guarantees that data is received. UDP is "connectionless".
If using UDP, be prepared to handle all those situations: missing datagram, duplicate datagram, or datagram in the incorrect order. Error detection and correction must also be handled.
With TCP, if a packet is dropped, but the next packet makes it through, the kernel withholds that packet until the earlier packet can be re-sent. This is because TCP is a guaranteed, in-order, stream protocol. This means that "fresh" data will sit in the kernel, while you are waiting for the TCP time-out and re-transmit. This takes a minimum of 3 seconds for a lost packet. Due to this limitation, UDP is usually better for real-time low-latency applications.
SocketDevice does not support acting as a server. Because UDP is connectionless, in order to receive UDP packets you need to act as a server, which is not supported in E-Prime. This means that UDP socket communication in E-Prime is entirely uni-directional.
If you need to receive packets via UDP, you will need to use an alternative method. The first solution is to write a custom DLL from E-Basic Script. PST strongly recommends reading through the Declare statement topic in the E-Basic Help (accessed via the Help menu in E-Studio) for more information on exactly how this can be done.
NOTE: This option is very advanced and should typically be handled by a professional programmer as it involves going through non-E-Basic code to determine which calls will be necessary in the experiment. PST cannot provide support for experiments that are using DLL function calls as the files themselves vary so much that we are not familiar enough with them to troubleshoot.
PST highly-recommends the use of packet sniffers such as Wireshark (
http://www.wireshark.org/) for debugging network communications.See Also:
INFO: How To: Socket Device Communication [25288]
INFO: USB device compatibility with E-Prime [19547]
Comments
4 comments
How to write a byte to socket device?
Any examples?
Thanks,
I think the sentence should read, "The first solution is to write a custom DLL to call from E-Basic Script." E-Prime is not capable of producing .dll files at all, it can only call DLL functions developed using another platform such as C or C++.
I can send data from E-Prime via either UDP or TCP, but cannot receive data via either protocol. In particular, I cannot start a TCP sender until E-Prime is ready to receive, and E-Prime will not run at all if something is not already running at the port for the Socket device, so it's a bit of a chicken & egg problem. What tests did PST run to verify that the Socket device can receive data, and how could we duplicate those tests ourselves?
Aha, I can get the Socket device to receive TCP packets if I first start a listener (e.g., with netcat), then I can send data from the external "listener" back to E-Prime.
Please sign in to leave a comment.