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 supports TCP (Transmission Control Protocol), UDP (User Datagram Protocol), and byte order selection.
The Socket device is added to an experiment via the Devices tab of the Experiment Object's property pages. For details about adding and configuring the Socket Device, please see DEVICE: Socket Device [26069].
E-Prime supports TCP and UDP communication in the following directions:
| Send TCP | Receive TCP | Send UDP | Receive UDP | |
| E-Prime 3.0.3.x | Supported | Supported | Supported | Supported* |
| E-Prime 2.0.10.x | Supported | Supported | Supported | Not Supported** |
| E-Prime 2.0.8.x | Not Supported | Not Supported | Not Supported | Not Supported |
* Only versions 3.0.3.60 and later are supported. Please see BUG FIX: UDP Sockets cannot receive data [25865]
** Receiving UDP data may be possible by first sending UDP data.
Generally speaking, TCP communication is slower than UDP but more reliable. With TCP, if a packet is dropped but the next packet makes it through then 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 waiting for the TCP time-out and re-transmission. 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.
In contrast, UDP communication is faster but less reliable. UDP does not guarantee the delivery of packets and if a packet is delivered then the delivery is not guaranteed to be in the correct order. UDP is faster but does not ensure that intended data will actually be sent. Because of this, UDP is often referred to as "connectionless". If using UDP, be prepared to handle situations such as missing datagram, duplicate datagram, or datagram in the incorrect order. Error detection and correction must also be handled.
PST highly-recommends the use of packet sniffers such as Wireshark (http://www.wireshark.org/) for debugging network communications.
Additional information on receiving UDP data in E-Prime
E-Prime 3.0 requires a Global StartupInfo parameter for each machine that runs E-Prime 3.0 with UDP sockets. The parameter can also be set in the StartupInfo prompts.
For example, if the hostname is PST123 and the IP address is 192.168.1.100, a Global StartupInfo parameter can be created on PST123 (i.e., the host machine; not the machine you are talking to) as follows
Socket.UDPRecvServer = PST123
When given PST123, WinSock attempts to resolve the hostname to an IP address and then bind one of the network interfaces to that IP. If the machine uses a dynamic IP address, just putting the hostname as the receive server will make sure that you always retrieve the correct IP address.
Note that this only works if the Socket Device is named "Socket". If multiple Socket Devices are being used, corresponding entries for each Socket Device will be needed (e.g., Socket2.UDpRecvServer).
If the hostname resolution fails, the IP address can be entered in the StartupInfo parameter.
To enable fully functional UDP sockets in E-Prime 3.0, Socket.UDPRecvServer must be set equal to hostname. This allows UDP sockets to be received without sending first and they can receive UDP packets from other machines.
The hostname is used to figure out which local network interface is used to receive packets. If testing locally, 127.0.0.1 can be used as the IP address.
NOTE: In order to send/receive information using UDP from two different E-Prime experiments on separate machines, the Global Startup Info parameter for Socket.UDPRecvServer needs to be specified in both experiments.
See Also:
DEVICE: How To Send Markers Through a Socket [25288]
OVERVIEW: Modifying StartupInfo using StartupInfo Editor [22727]
Using a Socket to send and receive TCP/UDP communication [42528]
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.